In the second blog post in this series, we explained that a lean QMS results in less complicated devices, which in turn decreases development time, cost, and, in many cases, patient risk. Less is more. Simplicity helps teams focus finite resources on the right tasks – which should be risk-prioritized. Ask anyone who has been through an audit: the more loose threads in a design, the more difficult the process.
Frustrations can build when excessive energy is spent on a feature that is not essential to the safety or efficacy of the device, and even more significantly, not beneficial to the patient. Frustrations multiply if the energy spent is due to a complicated process. But while simplicity is an objective, remember that there may be a decreasing return or ultimate boundary in the pursuit of it. As Albert Einstein is credited with saying, “Everything should be made as simple as possible, but no simpler.” When the simplified object or process no longer meets its determined requirements (which have already benefited from simplification), that threshold has been breached.
The ultimate goal for a design team should not be a complete simplification of the device; rather, the goal should be to provide the safest and most effective equipment for the patient in the most efficient way possible, while still meeting all stakeholder needs. Appropriate simplification demands that designers understand the difference between user needs and preferences to prioritize functionality and ensure that essential facets of design and usability are not left out. The same holds for internal process developers.
The responsibility for simplification should be distributed and not carried by system engineers alone; nonetheless, they can be internal champions for simplification, which works in their favor because complexity is likely to be heaviest on their shoulders. Still, simplification should be sought and applied across all disciplines in design, production, and processes.
At Velentium, we routinely use a technique called “kill, keep, or combine” to reduce the complexity of any topic across the company. For example, when brainstorming a list of features needed for improvement, the uninhibited list may be excessive and need filtering. The technique is simple: Apply one of the following to each item.
- Kill the item from the list (e.g., it is not necessary or useful)
- Keep the item on the list until next round
- Combine the item with one or more others, possibly creating a new item encapsulating them
This process is repeated until no further items can be removed or combined, and only the key entries remain.
But simplification is not just a matter of perpetual kill, keep, combine; it is asking the right questions in the proper order. It is valuable to mitigate business risks (which often relate to patient risks) as early as possible, and a big question answered too late can be tragic. This is well understood by venture capitalists, who ask questions like, “Is the device going to be clinically effective?” or “Is there a known path for regulatory approval and reimbursement?” For many startups, device development may not be the most significant risk. Teams must prioritize according to patient risk and business risk, with the former taking priority.
As a final reminder, the simplification process is not to cut corners; it is to ensure that the essentials are done as thoroughly and flawlessly as possible. It is far more essential to deliver an effective risk control than to provide voluminous yet uninformative risk analysis documentation (a.k.a. “risk management theatre”). The documentation must not obfuscate the critically important analyses and mitigations but instead must shine a spotlight on actual risks. This requires clarity in thinking and presentation.
Our fifth and final post is going to wrap all of our topics together and talk about why a company should go through this process. If you’d rather not wait, click here to download our QMS white paper.
If you would like to be notified when these posts go live, please subscribe for up-to-date email alerts.
