Velentium Blog

Embedded device cybersecurity is relatively new compared to our friends with the “big iron” in Managed Information Systems (MIS), so while there are many differences between the two domains, there are a few commonalities; tools and techniques that we can fork / modify for use in the embedded world.

Sometimes, your boss or client will ask for a miracle, such as a deliverable before you're ready. Like many of us, you'll probably feel tempted to avoid conflict and nod agreement. Under pressure, this often feels like the easiest way through. But it's fraught with risk: you're risking your reputation, your relationship with your boss, client, and team, and maybe even your job.

As we resume our discussion of Human Factors Engineering (HFE) for medical devices, it's worth repeating that HFE should be wholly incorporated into the development process. HFE is about thinking ahead to catch and prevent potential user errors before they happen. Ideally, iterative testing against anticipated use-based risk would be scheduled in lockstep with development phases.

Whether your team is floating new ideas during a brainstorming session or seeking approval on a controversial proposal, skepticism is inevitable. But is skepticism an obstacle... or an opportunity?

Welcome to my first blog posting on Embedded Systems Security.

Velentium hosts a company-wide monthly book club, seeking to learn from the best in business. This time, we discuss The Pixar Touch: The Making of a Company, by David A. Price.

It may feel counter-intuitive, but referring potential clients to companies that operate just outside your specialty or overlap with you can actually be a great way to build your network, develop your brand, and double-down on your strengths.

When it comes to medical device safety, having fully-integrated human factors engineering (HFE) processes in place throughout development is absolutely critical.

Integrating HFE from Day One of development may seem counter-intuitive. The iterative testing process HFE calls for can be frustratingly non-linear, and may appear expensive. But the alternative – taking a product all the way to pre-market testing before identifying potential user error – is much riskier. At that point, when testing reveals use-based safety concerns, you'll be forced to choose between a costly redesign or a hasty, less-than-effective retrofit. The further along in development your product goes before HFE integration, the riskier and more expensive neglecting it becomes.

Broadly speaking, HFE aims at reducing hazard risks arising from user error during normal use of your product. Successful HFE integration forces your whole development team to stay focused on users, use environments, and user interfaces throughout product lifecycle. HFE recognizes that a well-designed user interface (UI) not only encourages correct use of your product, but also discourages incorrect (and potentially hazardous) use errors.

Image Credit: FDA

(The FDA defines UI for medical devices as all elements of the device that a user interacts with – sees, hears, or touches).

It should come as no surprise that modifying product design is more effective at combating user-error hazards than training or labeling. Training is subject to “knowledge decay” – we forget training with time – and we don't necessarily have or take the time to locate and read instructions, especially in urgent medical situations. Users interact with devices primarily on intuition and expectation, biases and instincts which are reactions to product design and influenced by previous interactions with similar products. We've got to anticipate these and keep them constantly in mind in order to “design out” user error.

In general, the FDA believes that user-based medical device safety should be prioritized like this:

1. Safety Through Design
2. Protective and Preventative Measures
3. Safety Information and Training

One of the biggest challenges we face in design is the expectation of simple interfacing. I once heard a microwave repairman claim that they should put only "+30 second" buttons on microwaves instead of all the other numbers because that's the one that malfunctions from overuse.

Whenever you launch something truly new, you should expect to cause some confusion and misunderstanding - maybe even to encounter resistance. Even your target market might be unenthused at first. And you may chart multiple routes before finding your way.

When resistance happens, your response is critical to the success of the launch. If you respond in frustration or discouragement, you risk scuttling the launch just offshore. But if you remind yourself that the people you're trying to help haven't spent the same amount of time thinking about the problem the same way you have, and that everyone needs time to get used to new ideas, new processes, and new solutions, you'll be in a much better position to set sail. Optimism must originate with the founder!

Part of your job, post-launch, is to persevere in the same hope that caused you to start the project in the first place. Almost always, that will mean helping others recognize its value.  Often, it will mean re-clarifying your own vision. And once you are afloat, don't be surprised if you end up cruising along the shoreline right where the breakers break. It is hard. It is worth it! Stick to your vision and persevere!

Successful quality management for Software as a Medical Device (SaMD) will have 3 preeminent distinctives: