Risk Diagram: Part 2- Defining the design pathway from Initial Conception (Concept / Ideation)

The risk management for medical devices diagram begins from the earliest point of development

Was the iPhone truly a revolutionary design? Upon reflection, from the release of the iPhone in 2007 the majority of designs of smartphones copied the interface initially with a single home button at the base, before all evolving to a full button-less touchscreen 📱. However the iPhone’s impact was far more than its design form- it put a computer in our pocket. And we haven’t stopped looking at them, scrolling our thumbs up and down the screens, since. Hence we have the perception that the iPhone changed the world, but was it truly a revolutionary, unforeseen design, or an evolution of existing devices and concepts at that time?

Last issue, I introduced the concept of the risk management for medical devices diagram, which applies throughout the lifecycle of the medical device (and applies to device components for Combination Products). Notably it applies from the initial starting point- the Initial Conception, sometimes called the Feasibility Phase, or the Concept / Ideation phase.

Determining the activities to manage the risk will depend upon how much existing, predicate information exists which can be utilised.

In development, design concepts can either be; a complete copy of an existing product, a minor iteration, an “evolutionary design” or, at the extreme, a “revolutionary design”. To understand the inherent risks that the concept and product may have throughout the development cycle, it’s important to understand which of these areas the design and development is falling in to. Determining the activities to manage the risk will depend upon how much existing, predicate information exists which can be utilised. If the design and development is a minor iteration, likely there is significant information of the existing equivalent product. If the design is truly “revolutionary” a concept that has never been seen before, the effort of risk management will be quite significant to understand all potential risk elements.

Figure 1: The various design pathways versus the predicate assessments

Firstly, let’s look to the 4 different categories and the effort of work to assess the risk.

1. Complete copy of an existing product

I’m hesitant to use the phrase “me too” design due to its significance in regulatory applications. Though I have struggled when project teams have described the product as a “me too”, because I started to wonder what’s the marketing value of the product if it’s exactly the same? I can understand a product being considered equivalent to a competitor’s product, for example, where the competitor product has a significant market-share. Hence, releasing an equivalent product, potentially with a more respectable company branding image, may take some of that market-share. However, due to intellectual property rules, etc, I challenge if the product is a 100% copy, or if there’s a slight change in the design to overcome the patent infringement risk etc. In which case, pending on what is being determined as the baseline product, likely the design is not 100% equivalent and has a slight, minor iteration. When I’ve heard marketing colleagues arguing the case as a “me too” product, my challenge back is to differentiate versus the baseline (likely competitor) product- what is the value to the release of the product to the market if its exactly the same?

2. Minor iteration

Often the true situation relative to the scenario above, there are a huge number of potential minor iteration scenarios both from an existing concept point of view, but also with potential changes to a product launched to the market. Note though, in many cases changes to a post-market design and product must be considered with the same level of rigour of development and risk assessment as a product pre-market.

In addition to the competitor equivalent option described above, minor iterations may occur to existing products whereby a “tweak” to the design may be required. There’s potential overlap with scenario of changes to a post-market product (described next), however for a pre-market design, this could be a simple improvement based upon marketing assessment of an existing product in the field. Marketing formally requesting the change as a new development project.

However, the most significant risk is attempting to change a design as a post-market design change, for example due to feedback from users. Marketing may hear issues, or “requests” from users, patients for a released product and push to the development team to a design “tweak”. As noted last issue, I am personally loath to make changes to the design of a released product without full and formal assessment of the change through the development processes; change control, Design and Development Verification (or re-Verification as it would be), Design and Development Validation (or re-Validation).

For software, this could be the scenario of a “bug-fix” software release, being defined as required maintenance, leading to a “dot” release for a version of software X.1, for example. This would be deemed a post-market change and risk assessment would be required for the impact on the existing software’s Verification and Validation, at minimum.

For Software as a Medical Device (SaMD) or medical devices with software using AI, managing the changes in the post-market segment is a new challenge, due to the very nature of how AI works- it is inevitably changing.

Last issue I described the Point of Stability and how this point- where the product is Design Verified and Design Validated- thus the latent level of risk is the least. From this point, as the product is launched and being used by users and patients, the risks increase from use risks, due to the subjective nature of human use, or for hardware process risks. With AI, the use risks are even more significant due to factors such as the level of reliability and trust of the AI results (over-reliability / high trust or under-reliability / low trust in AI for example). But as the algorithms can potentially change and the source data changes with increasing use, this rapidly moves the latent level of risk away from the Point of Stability and is why risk management of AI in SaMDs or medical devices using software is even more important to keep that Point of Stability in mind. Are the changes sufficient to iterate the product back through the development process, ie to re-verify and re-validate? How will you manage that change in latent risk with your AI SaMD?

Manufacturing process changes may also lead to a potential specification change impacting the design. For example, choosing to “Design Transfer” a product to an alternative manufacturer may be deemed to be as simple as reproducing the existing product and hence it’s classed as equivalent (category 1). However, the number of changes and differences between one manufacturer and another would ultimately lead it to be a Minor Iteration (or even Evolutionary Design) scenario for the effort of work. From personal experience, I’ve never known a manufacturer to produce a product in the same method of manufacturing as another (and we’ll deep-dive on this another issue).

3. Evolutionary Design

The vast majority of development activities are likely to fall into this category. The level of effort, per Figure 1, may vary from the Minor Iteration, to significant development effort.

From a risk management point of view, the key to success is determining as soon as possible, what is/are the existing equivalent products and the levels of known information for how the product performs and thus it’s risks. This can be collating known information for a company’s own product(s) in the field, or researching for competitor products eg; utilising the FDA’s Maude database as example.

This is where quality personal can add value to the development process. Quality personal can be working on this information gathering whilst the initial development phase is progressing. It’s also one area where I envision and encourage AI tools to be utilised. This is a data-mining activity, which is a perfect task for AI and one where I can see efficiency improvements. Having AI tools search the databases, searching existing information, collating and documenting the known risks and presenting that information to the development team to support the initial phase of design and development effort. It’s crucial that a development team, the product development / design engineers are presented that information as early as possible in the design phase, to reduce project management risk of design changes later in development.

Are the changes sufficient to iterate the product back through the development process, ie to re-verify and re-validate?

Risk of late in development design changes to project / program timelines

Determining as soon as possible the information for the existing predicate products, enables the team to focus on what is different, what elements are new in the design versus the predicate products and design. For a new design to bring added value to patients and users, then likely it is to bring functionality that has not been seen before. Therefore, there’s less likelihood for existing information on that new design feature or function and hence where the team would need to put effort and focus brainstorming potential risks.

Whether AI tools have value in that brainstorming activity is an option and discussion for another time.

4. Revolutionary Design

Thus far, all design iteration scenarios we have described have been primarily reactive- ie either reacting to known issues or even oppurtunites for product(s) in the field, use issues or process and manufacturing issues.

Revolutionary design is to bring product and functionality to users and patients that they do not know they want or need. Functionality so much unforeseen, it’s a genuine welcome surprise to users. True revolutionary designs are rare.

Numerous development departments and product design consultancies have areas for creative brainstorming, with aim to bring revolutionary designs. However, what often transpires is that the resulting concepts are rarely revolutionary and would fall into the category of evolutionary. Arguably, SaMDs with AI could be classed as revolutionary and the lack of information and experience to manage latent risk falls into this scenario of effort in risk analysis. Yet, dig deep enough and there are some fundamentals in both the risk management process and predicate products that can still be utilised, even for this novel technology.

Similarly, developments from university institutions which evolve to become  “start-ups” can initially be considered revolutionary as technological functionality, however over time it begins to be determined that the application of the technology is often aligned to existing products and improvements therein.

For revolutionary designs, this requires the highest level of risk management effort as, by definition, nothing exists to compare the design concept with, such that significant brainstorming would be required to determine the potential Harms, Hazards, Hazardous Situations etc for the product. Clearly, these are the highest level of risk for product development ie not just the latent product’s risk (design, use and manufacture) but to the project, program management.

So, was the iPhone’s launch in 2007 a truly revolutionary design? I’ve dug out of the attic devices that I knew were lying in storage, being the electronic products I had at that time;

A Sony Ericsson P990i- a telephone, with a stylus activated touchscreen for inputting information, and a keyboard for ease of typing.

A Palm T/X, primarily a digital organiser, with a large touchscreen interface, a central home button at the base, but also stylus touchscreen interface. (With optional fold-out docking keyboard)

An iPod, my two variants here in photo; the original basic black and white screen interface and the more advanced version with colour screen and graphics- music in a small metal box.

When Steve Jobs announced the iPhone to the world in January 2007, he brought a design concept that ultimately brought together all the principals from these products (and similar) into one simple and functional form. Notably, he stressed the point that the iPhone would not be coming with a stylus (and to this day, none of the iPhones have ever been able to work with some form of formal stylus interface, though the Apple Pencil was brought out for all ranges of iPad including the iPad Mini- Jobs would have hated it)

There’s often discussion and challenge, especially for critics of Apple, whether they are ever first to market with novel designs, or just take existing concepts and bring out much improved versions. I personally believe generally it is the latter, though they’re not always 100% successful. Though, as I follow discussions and predictions on Apple technology forums, there are often occasions when features and functions are predicted and the resulting solution is beyond what has been theorised. Specific example being the “Dynamic Island” which was Apple’s efforts to incorporate the section for cameras and sensors on the front of the phone within the display to remove the “slot” design that had become common across all smartphone designs. The resulting software functionality for the Dynamic Island was far beyond anything that had been theorised on forums and I distinctly remember being impressed to see something unexpected.

Arguably the iPhone was not a revolutionary design, utilising many elements of existing products and concepts. It is hard to argue that the resulting product did not change the world significantly - for good or bad - because we know that Earth’s history was forever changed by the “breakthrough internet communications device” as Jobs described part of it’s function.

Understanding the basis of the design, either a simple iteration, evolutionary change or a radical revolutionary concept is the key first step in the determination of the existing information available to begin the risk management process.

Utilising AI to data-mine and collate that predicate information is a valuable activity and one that should be overseen by Quality experts, to provide the information to the product development engineers, whilst beginning to structure the risk management activities.

How this builds out to the other sections of the risk diagram will be dealt with in future issues. Next time we’ll look to the most pertinent practical next step of managing risk in early phase development- the importance of managing design iterations.