Open source hardware is an emerging business model where the design files of a product, including the circuit schematics, source code, and physical design, are made publicly available under a license so that anyone can study, modify, distribute, make, and sell the design or hardware based on that design. In recent years, three-dimensional printers have made possible a rapid production of customized medical devices [8], from fitted mechanical limbs [18] and mobile phone-connected microscopes [19] to parts for syringe pumps (as shown in Figure 1). Coupled with an open source approach, more can be achieved with less cost, because production can occur in-house, based on a freely available design.

Building on work of the Michigan Tech Open Sustainability Technology (MOST) group [20], we are demonstrating the process of building an open source syringe pump that implements design principles and interface guidelines published as part of the CHI + MED project. We are creating a complete open platform for further research and development [21]. Design files and software made public by MOST, under an open source license, are at the core of the project. The approach not only leads to economic savings through a reduction in the life-cycle cost [22], but also it allows others to improve on the design, share the improvements with others, and get rapid feedback from the end user. This openness can benefit multiple stakeholders and lead to effective technology and improved patient outcomes (for equivalent arguments relating to open source software, see [23]). It can also allow staff from hospital departments such as medical physics and clinical engineering to repair and customize their own devices, reducing a reliance on external providers.

The ability to modify someone else’s designs and the ease of rapid and unique production could interfere with formal quality-control processes, implicit in the existing medical device regulation. Although three-dimensional printing is a tool for prototyping and not for long-term use and reuse, it is possible to see how this technology could be used for the latter purpose.

Existing standards may not be practical as the documentation required for review and approval may be disproportionate when the design is limited to a very small number of production units. While the steps that are followed during the development and testing of medical devices are specified and controlled by standards (in the European Union, those listed in [12]), the process followed during the aforementioned activities may be ad hoc. For example, processes specified in medical device standards were created with traditional manufacturing process in mind. At a certain point, a design would be frozen and considered complete. This is not the case when devices can be continuously improved upon by the creator and others. The need for documentation and testing that closely adheres to standards may remove the flexibility that novel approaches bring. Repeated design changes and the requirement for oversight from a review body may be cumbersome on both sides. Although there are many advantages to realizing the benefits of existing process, systems need to be made agile and proportionate.

With an open source approach, there is an opportunity to share the rationale behind the design, the process used to derive the design, as well as the design itself. For example, online documentation tools such as wikis and version control software can be adapted to provide a better overview of the development workflow and process that has been followed. It is also possible to share evaluation results; if a component or design has evolved over time, knowing how and why this has happened could help those at distance understand the constraints of a solution. Through sharing and periodically updating these documents, duplication of effort can be avoided. For example, it does not always make sense for the same component to undergo the same testing by multiple parties. Moreover, documentation can be scrutinized by multiple specialists, without being confounded by the proprietary nature of “closed” solutions. Therefore, rather than requiring the same documentation as that for traditionally manufactured devices, regulation could involve transparent records of all components and changes made to those components, including the rationale and assumptions. This would help to support the quality of such devices without stifling innovation, with the onus being on those implementing a solution to check and review these documents.

Given the need to support care outside of clinical settings, technologies are also being developed to provide increasing autonomy and self-care. Our research on CHI + MED investigates how people use technology to manage their health care needs during their day-to-day lives. One such set of technologies includes devices used in the self-management of type 1 diabetes, a complex chronic condition that requires significant personal responsibility over a lifetime [24]. A common form of diabetes technology is the glucose meter that is used to measure blood glucose levels for everyday medication dose calculations, as well as for identifying high and low blood sugar levels, which are dangerous in the long term and potentially fatal in the short term, respectively [25]. Thanks to advances in technology and human factors engineering, glucose meters can be used by people with minimal or no training. They are easier to carry, easier to use, and can store results. This empowers people with diabetes and grants independence [26].

However, our work shows that complexities of everyday life such as people’s work life, romantic life, friendships, hobbies, travel, holidays [27], or whom they are with [28,29] impact on the use of these devices (Figure 2). Understanding these factors is incredibly complex [30], but necessary to ensure glucose meters are reliable and meet users needs. The problem is that the evaluation methods suggested by standards are not adequate in addressing everyday use, as they have been developed with a focus on technology used in clinical environments, where there is more certainty about the characteristics of the work place and levels of training.

Mobile health care technologies used for self-management, such as glucose meters used by people with diabetes, are medical devices and are regulated as such. Standard usability engineering process applies, such as IEC 62366 [14], for these cases.

These personal health care devices are used in the context of people’s everyday lives, yet the design and evaluation involves the same usability standards as medical devices found in hospitals. The definition of usability is the same (see [14]). The focus is on the device’s effectiveness, efficiency, ease of learning, and user satisfaction, in what is assumed to be a controlled context. This standardized usability evaluation practice makes it difficult to support the range of individual needs of users outside clinical environments: in their homes, on the go, as a part of their everyday life. This can be seen by accounts of the application of standard usability engineering process [31], such as IEC 62366 [14]. Although such standards are voluntary, and the techniques are illustrative, many companies feel that they have little option but to adhere to their content [32].

Although standards such as IEC 62366 [14] suggest taking context into account using techniques such as task analysis, contextual inquiry, functional analysis, testing in simulated clinical environments, and field testing, how they might be adapted or tailored to represent the unstable context of everyday life is not elaborated on. These methods may not capture the influences that a person’s life might have on the safe use and adoption of these devices, outside the confines of a hospital. Influences could include the emotional aspects of self-care or the social impact of bystanders, when using a device in front of others.

Likewise, it can be unmanageable to scope everyday health care technologies, for the purposes of making assumptions about their use. Pervasive technologies are used by all sorts of people, in all sorts of situations, and in all sorts of contexts. Individual differences are inevitable, and they have been shown to impact users’ experience and challenge the design and development of products [33]. This raises concerns for health care technologies where differences might result in safety risks.

These concerns can be addressed by limiting the scope to a certain user profile or context, but this may not be possible for medical technologies designed for a particular condition, not for a particular user group. Another approach is to configure products based on user needs, for example, allowing customization of the exterior shell [34] and/or allowing configuration of the user interface. This poses a dilemma for evaluation in that as the number of possible configurations increases, the burden associated with management, evaluation, and support also increases [35,36]. On the one hand, allowing for flexibility reduces the chance of nonadoption or noncompliance; on the other hand, complexity in the product adds to the resource required to develop and maintain it.

One option would be to increase emphasis on postmarket assessment, such as monitoring the use of equipment in context (including self-report), alongside conducting research to understand how users are really experiencing this type of equipment. Exploratory qualitative methods have been applied in other domains to focus on the situated use of interactive devices and they are also relevant here.

For instance, diary studies [37] involve users taking note of when, where, how, and why they use their device in their everyday life. They avoid the invasiveness of observation. Autoethnography, a form of self-study, is a quick and easy way to probe the everyday use of mobile medical devices [30]. Even though there has been progress toward using exploratory methods to investigate the context of use [38], standards are lacking in their treatment of situated user experience. Situated user experience relates to the notion that the localized context is an important factor in determining how people will experience and interact with technology. As it has been shown that context influences the use of pervasive health care technologies [30], testing technology away from this context (e.g. in a laboratory) does not anticipate how well the technology will meet the needs of the user. There is therefore an opportunity for standards to support consideration of a broader range of context, given the mobile nature of devices, and use outside of clinical settings. The inclusion of exploratory qualitative methods would allow for this by probing context of use and revealing of individual differences.

Whereas personal medical technologies can provide benefits to those who require specific equipment, dedicated mobile phone apps have potential to be advantageous to almost anyone. People have access to thousands of free health-related mobile phone apps [39,40]. They range from behavior change apps supporting people who want to improve their health and well-being [3], for example, apps supporting smoking cessation (eg, SmokeFree28 [41]), or providing informed choice regarding alcohol intake (eg, Drinks Meter [42]), to apps focusing on specific conditions (eg, pain management [43]). They can be used to prevent forgetfulness (eg, medication reminder apps [44]) and general adherence support apps [45]. As people tend to keep their mobile phones close and hardly ever switch them off, health apps can provide useful functions at any time. They are always at hand to help track the on-going behavior.

Another (currently unreleased) example would be a software app to support oral contraception adherence. We are currently researching how mobile phone apps could be used to reduce unintentional nonadherence. This involves developing a medication reminder app that supports the formation of medication-taking habits and assists users as they search for the best way to embed medication taking into their daily routine; how this could be achieved is described in [44]. One of the major challenges to understanding the approach required to evaluate this type of software is the fact that it is not entirely clear whether an app should be regulated as a medical device.

During our research we have identified many issues concerning the certification of health-related apps. One example relates to the wording that is used to describe them. Many apps make medical claims and by doing so, could pose a serious public health issue, especially they are if ineffective or inaccurate [40]. Regulation is required and although guidance on health-related software and apps exists [46-49], it may not be clear whether such apps should be covered by regulations. Moreover, when considering the market as a whole, regulations may be bypassed and in some cases, ignored. In the European Union, in some cases, health-related apps fall under the control of the medical devices directive. In this scheme, assuming the software is not an accessory to a device, classification rules can treat medical standalone software as a comparatively low risk [49]:

“The classification rules were not written with software in mind. Due to the restrictive nature of Rules 9-11 of Annex IX to Directive 93/42/EEC, a large number of software devices therefore fall in Class I, where compliance is based on self-declaration, ie, no third party assessment.”

As a result, the product can be self-certified by the organization producing it. This raises concerns about the level of peer review and testing that this type of software receives.

In other cases, software can be used in a medical context, but not for a medical purpose, and not considered to be a medical device. For example, based on similar UK Medicines and Health Care Products Regulatory Agency (MHRA) advice, an app could use an accelerometer or gyroscope to detect falls in epileptic patients and therefore be regulated as a medical device. However, if the same technology is used to measure steps or detect whether an elderly person has got up from a chair or a bed in a social care context, the regulation would not apply [47]. This is important because it impacts on the type of testing that would apply (both in terms of usability and general safety and performance requirements), as well as the approach to monitoring the device in situ.

To help determine whether an app should be treated as a medical device, the MHRA has produced the following list of keywords and phrases that if used in the app’s description indicate that it should be regulated: amplify, analysis, interpret, alarms, calculates, controls, converts, detects, diagnose, measures, and monitors [47]. Take the example of an app that aims to send alerts to users to check whether they have taken their medication and records how many times they say they did not. Based on this information, it can suggest changes to the routine. Therefore, it could be said that the app monitors users and occasionally alarms when their behavior needs to be modified. Does it mean the app should be certified?

If the app is labeled as a tool for supporting medication-taking habits, then the answer is likely to be yes. However, if the wording changes to simply habits, then even though the functionality stays the same, does the answer become no? Such a small change in wording could be enough to avoid device regulations, but it might not even be needed. Some developers simply publish their health apps without worrying about regulations at all, whereas others add liability disclaimers to app descriptions [40]. Based on the US guidance relating to mobile medical applications [46], “Mobile apps that keep track of medications and provide user-configured reminders for improved medication adherence” are an example of “...mobile apps for which FDA intends to exercise enforcement discretion” [46].

Based on both US and UK frameworks, this type of app may or may not be regulated. This problem has been covered in recent UK media reports [50], where there are several examples of gray areas and products that sit on the boundary. In many respects there is not anything new about technologies that sit on the boundary between regulated and unregulated products. The concern is that the assumptions used to determine whether technology is regulated as a medical device may not reflect how the technology is actually used (eg, unregulated apps being used in a context when a regulated app is appropriate).

Of specific concern is the quality of the software code and process used during programming, which may be invisible once the software has been released. Even if there is intent to follow medical device standards, they may be difficult to realize in practice. For example, the medical device usability standard IEC 62366 [14] combines evaluation of safety and usability, which may be in opposition to each other [35]. Other standards may be insufficient when it comes to the testing of software: they may not require exhaustive testing, complete coverage, or proof that a solution is correct by construction [51]. This is evident in the number of software-related defects observed in medical device user interfaces [52].

Because of the intangible nature of apps and the fact that they can be easily updated in situ, assessment and classification at a single point in time may not be feasible or appropriate. Obiodu and Obiodu [40] suggest that one way to deal with the issue of certification might be producing evidence-based guidelines for designing health apps rather than trying to strictly regulate them. We agree with this point, but would see an opportunity to take this further. Rather than just relying on guidelines issued by authorities, patient groups could produce best practice guidelines for specific conditions and, by following the example of open hardware initiatives, publish them openly to encourage collaboration with other patient groups, app developers, and mobile phone manufacturers, who are already starting to release health care kits [53].