Farms product strategy, technology and development services are comprehensive.

Farm Blog

Cybersecurity 101: Making Medical Devices Secure AND Usable

Posted by Chris Thurrott on Thu, May 11, 2017

Cybersecurity 101: Making Medical Devices Secure AND Usable

Medical devices are becoming increasingly pervasive and interconnected, with hospitals averaging 10 to 15 network-connected devices per bed. 90% of hospitals were victims of cyber-attacks in 2014 and 2015, and it cost the healthcare industry $6 billion to address these attacks. Healthcare (unfortunately) is becoming the most victimized across all industries, accounting for 27% of all breaches in the first half of 2016.

H1 2016 data breaches by industry

It’s important now more than ever to control access to medical devices so only the right people can do the right things with them. Also known as access control, authentication, or identity management, getting cybersecurity wrong can lead to security problems, poor usability, or both.

What kinds of security problems?

  • Multiple parties have demonstrated that it is possible to gain control of certain insulin pumps and remotely perform actions such as wake up the insulin pump, start and stop the insulin injection, or immediately inject a bolus dose of insulin into the human body.
  • A pacemaker manufacturer recently had to issue patches for a security hole that could allow an attacker access to implants remotely. The attacker was able to issue catastrophic commands like generating shocks or disabling the implant over a wireless network. Unfortunately, the manufacturer sustained a costly hit to its stock price.
  • Hackers can exploit insecure medical devices to attack a health facility’s entire network. Separate attacks on two U.S. hospitals took one facility’s computers offline for a week, while another had to notify over 30,000 patients that their records had been deleted and potentially disclosed to the attackers. In addition to higher operating costs, impaired patient care, and having to pay for credit monitoring for affected patients, these facilities also had to pay ransom to the attackers to get their systems back online.

“Just lock it down” doesn’t work.

After reading the examples above a medical device developer might be inclined to enforce rigid security requirements, like 20-character complex passwords that must be changed every 7 days. Don’t do this.

XKCD comic on password strength misconceptions

An overly complex password can provide a false sense of security and can lead to problems like the following:

  • One system timed out every five minutes, requiring the user to log back in. That translated into the clinician spending 1.5 hours of each shift logging in.
  • Another system prevented users from logging in if they were already logged in somewhere else. So if a clinician going into surgery discovered she was still logged-in outside the operating room, she’d either have to un-gown or yell for a colleague in the non-sterile area to go log her out.

When users, especially in health care, are faced with obstacles to getting their job done, they get creative in working around those obstacles, making the systems less secure. Researchers looking at this topic found the following workarounds:

  • Putting Styrofoam cups over proximity sensors or having a junior team member repeatedly press the spacebar on everyone’s keyboard to prevent timeouts during a procedure.
  • Sharing passwords to a medical device among entire hospital units by taping the password onto the device.
  • Sometimes well-intentioned medical system manufacturers encourage workarounds, like distributing this sticker (branding altered to protect the guilty).

Password reminder sticker and instructions

Workarounds like these can cause problems with inadvertent or unintentional exposure of protected health information as well as accidents, such as entering a medication order for the wrong patient, because the previous clinician did not log out properly.

Make it usable AND secure.

Logging in is never a primary user goal; users log in so they can accomplish some other task. It’s essential to make authentication as easy as possible for authorized users while preventing those without permission from using the system. Medical device developers should minimize these distractions so users can focus on necessary tasks.

One place to start is to carefully develop a threat model, analyzing which interactions with a device are higher risk and need securing. For example, knowing that the infusion pump is running or infusion time remaining might be lower risk and not require login, while changing the dose is probably higher risk and needs to be password-protected. This way, the user can still get needed information from the system without having to expend time and effort logging in. Once a user is logged in, they should be able to take “protected” actions for the duration of their login session. Forcing authentication for each individual feature leads to choppy workflows and potentially insecure workarounds.

If your system requires users to log in, consider ways to reduce or eliminate the need for them to memorize and enter information. They have enough stuff to remember for their “day job.” Consider the following:

  • Authenticating with a badge or fingerprint.
  • Show a list of users so people only have to remember their password.
  • Simplify the password to a number or shape.
  • Minimize or eliminate complex password “recipes”

Simple password examples

It’s important to consider everything that could go wrong, and give the user a clear path to resolving problems. As medical device developers, one way we can do this is by providing clear messages for authentication errors, a means of resetting a forgotten password directly on the device, and a way to get help if the user cannot resolve the problem independently.

We also need to consider carefully how and when to end a user’s login session. If the session ends too soon, it could interfere with the user’s work, but waiting too long could leave the session open to misuse by unauthorized and authorized users alike.

Creating usable and secure systems starts with understanding the user’s workflow and adapting the system to it. This is much easier than changing human behavior. We should observe users performing their work in context to answer questions like:

  • What information do they need? What actions are they taking?
  • How often do they need to interact with the device? For how long?
  • What else are they doing? How often are they interrupted?


In the U.S., the Food and Drug Administration is applying increasing scrutiny to cybersecurity, issuing guidance on cybersecurity documentation needs for premarket submissions and maintaining a repository of additional resources. Medical device developers need to consider security throughout the product development process.

In the end, medical products need to address both usability and security concerns to minimize risk, be effective, and achieve market success. Considering them together, rather than separately, will result in a more balanced approach.

Sources and further reading


Topics: user needs research, Medical Device Development, cybersecurity

Human Factors in Design: 3 Cognitive Patterns to Keep in Mind When Designing a Product

Posted by Kate MacNamee on Thu, Mar 2, 2017

3 Cognitive Patterns to Keep in Mind When Designing a Product

Human factors research is often described with a focus on human behavior: what is the user doing, what did they press, click, or move, and how? This doesn’t always get at the heart of an issue though. Just as important as what the user did, is why they did it. The most effective human factors research, especially when assessing risk, doesn’t focus solely on user actions. Instead, it recognizes that the user is part of a larger system. Yes, it exposes how device design and interface structure affect user behavior, but it also considers the fact that behavior may stem from the cognitive patterns and mental models that users themselves bring to the system.

Although usability testing is an important step in evaluating the design of a device or system, designers and engineers can use already-known patterns of human cognition to get a head start designing products that are less prone to use error and that work with the way our brains work, rather than against. This article is meant to provide product development teams with a brief introduction to a few psychological principles that can allow us to do just that.

1. Recognition beats recall (and working memory)

The Fact: Our brains are already working hard to get us through the day, especially in healthcare settings where there may be a large amount of activity in a small space, both physically and temporally. However, the brain’s resources are finite; the more the brain is required to pay attention to a task, the fewer resources it has left to allocate to other tasks. Such a task could include noticing an alarm or holding information in short term memory. This means that complicated products with a large number of steps and options may be more prone to use error. The average working memory capacity is 7 items +/- 2 items, so asking users to remember even up to five pieces of information could prove too taxing.

The Solution: When complexity is unavoidable, products that ask users to remember as little as possible often work best. Memory is one of the more effortful processes at our brains’ disposal. Incorporating features into an interface that prevent the user from having to recall a step or an item location freely will make for better products. Cueing participants with meaningful icons, effective drop-down menu headings, and transparent or shallow interfaces in which the organization of information is conveyed, can absolve users from having to remember the path they last took to find a certain piece of information or complete a critical step. The ways a designer chooses to require recognition (or not) by the user as he or she uses an interface can vary, and they often depend on user expertise, automaticity, workflow, etc. Still, it’s valuable to consider, and to minimize where possible, the amount of cognitive resources we ask users to employ.

2. Primacy and recency effects

The Fact: When people hear or read a list of steps or items, they tend remember the items near the beginning and end of the list better than the items closer to the middle of the list. These patterns are known as the primacy and recency effects, respectively.

The Solution: In scenarios where multiple steps or items need to be remembered to use a device correctly (e.g., a list of warnings in an IFU), consider positioning the items that are most important to be remembered near the beginning of the list. Before placing important items near the end of a list, however, consider whether users are likely to read the entire list.

3. Affordances are everywhere

The Fact: People attempt to use objects in ways that are based on affordances (the perceived ways in which a user may interact with an object, device, or system). Affordances may be communicated to a user through an object or device’s shape, texture, or other characteristics. When a product provides affordances that are consistent with the way it is intended to be manipulated by its user, we call the product intuitive or user-friendly, because we understand how to use it without having to learn. Affordances can be rooted in the way our bodies naturally interact with the physical environment, or in the way our cultures and experiences have shaped our perceptions over time. Don Norman, author of The Design of Everyday Things, one of the seminal books on usability, famously discusses the affordances of doors. Most people have tried to pull a door they should have pushed, or vice versa, and then felt a little embarrassed for doing so. Luckily for all of us, psychology suggests these mistakes aren’t ours, but are the fault of doors that convey the wrong affordances. Vertical door handles that are easy to wrap your fingers around afford a pulling motion, while flat plates or horizontal bars affixed to the face of a door afford a pushing motion. Doors that appear to afford one motion but that require a different motion from the user to work (e.g., a door with a vertical handle that must be pushed to open) are called “Norman Doors.” By understanding affordances, we are less likely to design “Norman Products.”

The Solution: Think about how you can communicate your product’s intended use through design affordances. If a heavy monitor should be lifted using two hands, provide two obvious handles on either side of its body that can be gripped while the user’s wrists are in a neutral position. If a needle cap should be pulled straight off and not twisted off, place ridges on the cap that are aligned perpendicular to the pulling motion required. The ridges are visual and tactile clues for the user who can perceive that they would only provide useful friction while pulling and not twisting. These are just two simple examples; the list of example affordances that can be used in product design goes on and on.

We’ll never be able to fully predict user behavior, so usability evaluations and validation testing to ensure safe and effective use will always be important. However, we can use our understanding of psychology and cognition to inform our designs and get a head start when it comes to designing products or medical devices that are intuitive and less prone to use error.

Topics: product development, human factors, product design

The Case for Words in Medical Device UI

Posted by Chris Thurrott on Thu, Jan 5, 2017

Medical Device UI

“A word is worth a thousand pictures” – Bruce Tognazzini

While it is possible to communicate using only pictures (just ask the ancient Egyptians) it is almost always better to use words as well. You might have been able to parse the picture above, but it was undoubtedly easier to read the words in the title of this article.

A request we often hear when beginning a graphical user interface (UI) project is to minimize (or even eliminate) on-screen text. Project teams think that icons will make the medical device easier to use, and/or that text is too difficult to translate. While including properly tested icons and other graphics can aid usability and make a UI more appealing, relying on them exclusively can actually make medical products harder to learn and use.

Here’s why you should use words in your medical device UI, and some tips on how to make internationalization (I18N) easier for your team:

Enhanced Usability

As the Nielsen-Norman group writes, there are only a few icons that users will instantly recognize, and these are for simple concepts like “home” and “search”. Trying to represent more complex concepts such as those found in the medical world will lead to confusion unless the icon is accompanied by text. What’s a good icon for “analyze”? For “therapy”? A good rule to follow is that if it takes you more than 5 seconds to think of an icon to represent something, it’s unlikely to be understood by a majority of your users.

Even if it’s easy to determine what an icon is (a heart) it might be difficult to figure out what the icon means in the context of use (is it related to “favorites”?  “cardiac function”?)

Compliance with Regulations and Guidelines

In the United States, one of the factors the Food and Drug Administration considers when evaluating applications to market medical devices is adherence to design guidelines such as AAMI HE:75 Human factors engineering – Design of medical devices. This document’s advice for medical product designers includes:

  • Use symbols only if 85% of intended users recognize its meaning in a specific clinical setting (section 10.4.3).
  • Never use illustrations and graphics instead of text for instructions. Only use graphics to help users understand the text (section
  • Include text labels with icons wherever they are used (section
  • Use graphics and white space to enhance understanding and make the device look less intimidating (section 21.4.7).

All of that being said, the inclusion of graphics and icons can have benefits, including:

  • Faster control recognition
  • Larger and more uniform targets make it easier to tap or click
  • Lower information density provides a less intimidating appearance
  • Illustrate concepts that are hard to describe in words
  • Users can more quickly interpret proportions and trends communicated with graphics than with numbers
  • Visual appeal

The takeaway is that you can and should use icons and graphics where it makes sense but you have to back them up with text to assure usability.

Using Your Words

A user interface is a conversation between your product and users about what users want to accomplish and how the product will help the user make that happen. It’s vital that both parties are clearly understood. The words you choose for your interface matter, so always be thinking of the person who will be reading those words. What do they need to know at each step? How can you explain it briefly and clearly?

Once you have the right words, you will need to translate them for use in different countries. For many types of medical products, you will be required to translate the instructions for use and other training materials for each locale. If you set things up properly in your software you can leverage this work for the UI text as well.

It starts with the user interface design and layout. Different languages will require different amounts of room to express the same thought. Here’s an example from AAMI HE:75 (table 21.4):

AAMI HE75 Example

Languages can also vary in other ways, including:

  • Sentence structure – adjectives come first in English, second in Spanish and other languages (see “pure oxygen” above).
  • Use of gender – English is neutral, while Spanish and other languages use masculine/feminine nouns and articles.
  • Reading direction – English and other Western languages read left to right, while Hebrew, Arabic, and others read right to left. Happily, languages like Chinese that were historically written vertically have evolved toward horizontal orientation, especially in the computer age.

All of this impacts developing your software code, but don’t despair. Following the tips below will help you smoothly internationalize your product and also benefit your English versions (cleaner designs, easier to update labels, etc.)

  • Choose frameworks and fonts that support string extraction and international character sets.
  • Extract text like button labels and error messages from your code base. This makes it easier for your software to switch languages on the fly and provides a ready-made work list for your translation provider. Don’t include text in your graphics either.
  • Keep text brief and clear to start with. Watch out for idioms that won’t translate.
  • Leave room for text expansion. Languages like German and French might need 25% or more additional space, but it’s best to look at the specific words and languages in your product. Methods like flexible layouts and placing labels on top of data fields (instead of beside them) can help.
  • Do a test run on your mockups with a machine translation service like Google Translate so you can find design issues before coding. Always have a native-speaking subject matter expert check the final text.
  • Start early and do your homework. Careful planning and early testing will help avoid problems when you’re ready to launch. Articles from Intel, PhraseApp, and product engineering blog Zühlke are a good start for more in-depth tips.

Topics: medical device, user centered design, user interface

Prototyping Your Medical Device User Interface to Reduce Cost + Risk

Posted by Chris Thurrott on Wed, Nov 16, 2016

Medical and life sciences devices are packing greater functionality into sophisticated workflows involving screens and hardware controls. Regulators and an increasingly sophisticated user population demand that these devices be safe, effective, efficient, and appealing. Following a user-centered design process that includes human factors usability testing is essential to achieving that result.

It’s vital to gather user feedback early so that changes make it to the final product. Good user experiences don’t happen by accident, or on the first try. And the rework involved if you discover usability problems in a production-ready product can be incredibly expensive. So, how do you get the input you need without breaking the bank?

In the software world you develop iteratively. You release version 1.0, then react to market feedback, because developers can make and deploy changes quickly. But this is harder with medical and life sciences devices whose hardware and embedded graphic user interface (GUI) software is tightly intertwined.

The answer is to use a prototype, “something that makes your ideas ‘real enough to feel’ so you can get feedback from users.” Just as the physical aspects of a product are modeled with increasing levels of fidelity, user interface prototyping progresses through several stages according to where you are in the development process and the kinds of questions you need users to answer. Here’s how to use prototypes appropriately for where you are in your development process.

“I’ve got an idea…” – Low Fidelity Prototypes

When you’re in the early stages of a project, it pays to explore many different approaches. Low-fidelity prototyping gives you time to generate more ideas instead of sweating the details on only a few, and keeping the investment low allows you to throw away ideas that don’t work.

For example, on a recent food tracker project, we wanted to explore some of the following questions:

  • When people look at the device, is it to check status or take an action?
  • What actions are most important? Most urgent?
  • What’s the most important data? What data can we get rid of?

We began by sketching on paper so we could concentrate on ideas vs. design details. We came up with concepts that represented a range for each of those questions. Once we had a good variety of approaches, we sketched them in PowerPoint to share with the rest of the team.

Keeping things simple helps you, your users, and your stakeholders focus on what’s most important at this stage:

  • Overall organization of functions (conceptual model)
  • Information hierarchy
  • Navigation

Here are some examples of the many low-fidelity prototyping tools available:


Prototyping on paper is easy to understand, fast, and inexpensive. Grab a notepad and some markers and have at it. It doesn’t have to be fancy; it just has to communicate your design.

Once you have a set of screens, run a quick usability test by simply stacking up your screens and asking users to point to what they would tap or click on. Then make quick changes by overlaying sticky notes.

If you want to automate things a bit more, snap pictures with your smartphone or use a tool like POP (Prototyping On Paper) for even more interactivity.

Microsoft PowerPoint

Almost everyone has access to PowerPoint and its simple drawing tools. By using these tools and PowerPoints ability to import icons and other images, you can quickly build concepts to show users, and share files with other members of the team so they can add their own tweaks. You can even add animations and hyperlinks to make your prototype interactive and get a better idea of where the design can be improved.

Balsamiq Mockups

Balsamiq is a powerful tool for quickly building user interfaces. It has a huge number of built-in controls that you can drag, drop, and rearrange. Its goal is to be as fast as paper sketching while still providing the advantages of drawing digitally. It lets you make changes without starting over, reuse elements over multiple screens, and has the ability to resize and rearrange graphics.

Another great Balsamiq feature is its “sketchy” appearance. Having things look a little rough reminds the team that the design isn’t final, and prevents people from getting hung up on appearance when giving feedback.


“How will this really work?” – Medium-Fidelity Prototypes

Once you’ve decided on an overall approach, you’ll want to design more of the key workflows and conditions users will encounter in the real world, such as initial startup, normal use, and error conditions. Making sure you think about every conceivable state of design will prevent surprises when you get to development and help ensure a seamless user experience.

Prototyping at medium fidelity helps you evaluate questions like:

  • What’s the right amount of information density on a screen?
  • What terms make the most sense to users?
  • How can we use color, icons, and graphic design to communicate information simply?
  • How well does my screen interact with physical buttons and other interface elements?

On slide 1 - Here’s an sample from our food tracker, showing the hardware buttons drawn on-screen so users can click them.

As you can see, we’ve added colors, icons, and a schematic of the hardware buttons. Adding these details and testing them with users helped us change course and gave us more confidence that we had addressed the riskiest areas of the design.

At this stage you’ll be sharing the designs in progress with an increasing number of stakeholders on your team. Showing them prototypes helps you gather input, build support, and uncover design issues more effectively than written specs or static wireframes.

A helpful tool at this stage of the process is InVision.

InVision is an online prototyping and collaboration tool that’s quick to learn. You create screens in your drawing tool of choice and import them to your InVision project. You then link the screens using “hotspots” to simulate workflows. Users click the hotspots to simulate tapping the hardware or software controls, and the app even simulates gestures like swiping and double-tapping.

When change the design (which should be happening often as you iterate), all screens are updated, with InVision maintaining hotspot locations and a version history of each screen.

The prototype can then be shared on the web or loaded onto a tablet or phone for testing offline. The LiveShare feature lets multiple remote collaborators work on the design together, allowing them to point and sketch on the screen so everyone sees what part of the design is being discussed.


“Let’s build this thing” – High-Fidelity Prototypes

After several iterations of designing, testing, and refinement your team will be converging on the final design. Now is the time to make sure you get the nuances right, and can clearly describe every detail to the people who will be implementing the design. High-fidelity prototyping tools can help you experiment with more complex interactions, communicate the design to the development team, and begin testing the design on real hardware.

If you are blessed with a development team that is close by and can rapidly implement the user interface, you might be able to skip a high-fidelity prototype in favor of coding the real thing. If not, prototyping can help reduce your risk.

For example, our food tracker relies on a slide-up keyboard that animates into position. Trying to describe the slide-up gesture, the animation, and the appearance of keys being pushed with nothing but static screen images or text left a lot to (mis)interpretation. With a high-fidelity prototype we were able to clearly show the developers our intended product behavior.

Here are a couple of high-fidelity prototyping tools:

Axure RP

Axure RP has vast libraries of pre-built controls (buttons, text fields) and behaviors that let you simulate data entry, conditional logic, and animations. For example, you can allow a user to enter data by tapping on the keyboard, animate the keys pushing in and out, and then take different actions based on what value was entered.

You can build your screens with Axure’s built-in drawing tools or import from other drawing software. One of Axure’s more powerful features are “Masters,” which let you create reusable components so that visual or behavior changes can be made in one place but applied throughout your prototype.

Crank Software Storyboard Suite

Crank Software’s Storyboard Suite bridges the gap between prototyping and production-level implementation for embedded devices like medical products. Using the suite’s Storyboard Designer component, you import Photoshop files and link them into a prototype. Developers then import the prototype into your target hardware where the Storyboard Engine component translates your screens into real code for production deployment. This bidirectional workflow lets your designers and developers collaborate closely to fine-tune the design as you go through formative and summative testing.



User interface prototypes can help you lower project and usage risks while shortening the development cycle and reducing costs. They can help you understand what your users need and ensure that your whole team has a shared understanding of the product design.

And remember these tips:

  • Start small – prototype the user’s main workflow(s) and areas where use errors or safety issues could occur.
  • Test your design with users early and often. The earlier you find issues the less costly they will be to fix.
  • Don’t overinvest – you need to be willing to throw away what you’ve done.
  • Start with low fidelity prototypes to get the right organization and navigation scheme.
  • Progress to medium fidelity prototypes to work through design details.
  • Finish with high fidelity prototypes to test nuances and communicate to your team.

Topics: medical device, prototyping, user centered design, user interface

Overview of Latest FDA Guidance Documents for Medical Device Development

Posted by Kate MacNamee on Wed, Aug 31, 2016

The FDA recently released the latest version of three guidance documents addressing unique device identifiers, adaptive study designs, and real world evidence in regulatory research. In addition, two guidance documents related to whether a 510(k) is needed when making changes to an existing or pre-amendment device were released. To get a better sense of what these guidance documents will mean for medical device product development, we took a closer look at each, and have provided our insights below.

FDA Guidance’s

Adaptive Design for Medical Device Clinical Studies

Adaptive studies involve a prospective (i.e., a priori) alteration to the clinical study protocol, and often require careful planning in the design phase. This guidance relates most strongly to feasibility studies or pivotal clinical trials, and provides important suggestions and parameters for the conduct of such studies to maintain proper empirical and ethical boundaries during the course of research.

At the core of adaptive design are two principles: plan ahead, and be transparent. All plans to change the study protocol, whether the change pertains to sample size, longevity, or analysis, need to be justifiable for the benefit of the study and, most importantly, the benefit of the patients and end users of the device being tested.

Unique Device Identification System: Form and Content of the Unique Device Identifier (UDI)

In September of 2013, The FDA came out with the Unique Device Identifier (UDI) rule, which states that any medical device used and marketed in the United States must have a UDI, which an FDA-accredited facility would provide.

The UDI must be present in two forms: plain text as well as automatic identification and data capture (AIDC) technology (i.e. barcode or similar technologies). The plain text is present so that health care providers, patients, FDA members, and other device users accurately record and enter the UDI as data when needed. AIDC technology, on the other hand, allows for fast and accurate data communication and record keeping within and across facilities.

The guidance itself is short and to-the-point. It totals ten pages, and provides instructions as to acceptable sources and technologies needed to obtain a UDI for your product.

Use of Real-World Evidence to Support Regulatory Decision Making for Medical Devices

This draft guidance is meant to supplement and support the regulations already in place for evidentiary support in medical device approval applications. It details the types of real-world data (RWD) that have the potential to inform the FDA of device use patterns and efficacy. Examples of RWD might include administrative and claims data, quality improvement registries, and electronic health records (EHRs), and it can be helpful when sponsors are looking to conduct postmarket surveillance, expand indications for use, carry out post-approval surveillance commitments, identify a control group, etc.

Still, the guidance emphasizes that the consideration of this type of data is varied, and its acceptance depends heavily on the extent and quality of data that sponsors are able to obtain. Some sources of RWD might be appropriate for postmarket surveillance only, whereas others might also be able to inform premarket decisions regarding product safety.

The inclusion of high quality (reliable across collection sites and/or over time) RWD as evidence in both pre- and postmarket development can be a cost savings and might prove useful for those products which significantly benefit patients, therefore, it should be distributed as soon as possible. It is important to keep in mind, however, that RWD could still fall under investigational device exemption (IDE) regulations, and whether or not IDE regulations apply would be determined on a case-by-case basis.

510(k) Submission for Existing and Pre-amendment Devices

The FDA also recently released two guidance documents to help sponsors and manufacturers determine whether a new premarket notification or 510(k) is needed when making changes to an existing or pre-amendments device. One is for devices, generally, and the other is for software products. There are a series of very helpful flow charts within the guidance documents that help manufacturers determine the need for a new 501(k). Ultimately, however, the FDA asserts that they will make decisions on a case-by-case basis. The dynamic nature of the medical device field makes it difficult to create hard and fast rules that can apply to a diverse set of devices. These guidance documents do their best to convey the types of changes that will require a 510(k) by emphasizing that, at its core, a 510(k) is required when changes to the device significantly affect the safety and risk associated with proper use of the device. This might seem somewhat vague, but it can be applied to everything from labeling to material changes. When making the decision as to whether or not your device will require a new 510(k), it’s best to refer to the flow charts provided or communicate directly with the FDA.


Topics: product development, medical device, Medical Device Development

Medical Device Materials: Turn Up the Steam with Polypropylene

Posted by Bob Ketelhohn on Fri, Jan 29, 2016

It was not that long ago that when a client mentioned the words “plastic part” with “steam sterilization,” the only medical device material options that came to mind were high-end plastics like PPSU (Radel®) and PEEK. Yes, those materials are expensive in the plastics world, but they work and are known quantities. As my college statics professor always said, “When in doubt, build it stout, out of things you know about.” Good advice, unless cost suddenly becomes priority number one. Increasingly today, polypropylene (PP) is successfully going toe-to-toe with far more costly materials in the steam-sterilized medical device market.

I’m one of those odd engineers who actually enjoy going to plastic compounder conferences for material technology updates. Over the past few years, PP has shown up more often in the high-performance technical offerings in which durability and steam sterilization are combined requirements. What’s not to like? PP offers strong resistance to steam sterilization, very low cost, a wide array of mechanical performance characteristics achieved through different additives, and even recyclability for increasingly landfill-averse European markets. PP also has one major advantage that the others are still trying to figure out: soft elastomer overmolding that is chemically bonded. More on that later.

I was curious, so I went to and looked up the overview of mechanical properties for a few of the more popular steam-resistant plastics used in structural components.

Medical Device Materials Table






As you can see from the general numbers listed above, PP is not that far off from the other materials in terms of strength, particularly when you start adding glass. There are also more exotic ways to strengthen PP, like adding long glass fiber or carbon fiber, but then you lose the cost benefits and molding tool life. Now, would I go out and replace every laparoscopic scissor/grasper handle with PP? Probably not, considering the high loads and precision feel required in those tools. However, there are plenty of other, less functionally critical medical device parts that should be considered. As I wrote in a previous blog, Intelligent Engineering: Utilizing Data to Impact Tomorrow’s Design, finite element analysis is a helpful tool for making material decisions by providing preliminary feasibility simulations.

Recently, I worked on a grip component that was a legacy part made from injection-molded PPSU. While surgeons do grip this particular part, there are no major bending loads translated through it. The designers refined the ergonomic shape while I worked with material suppliers to come up with the ideal steam-capable plastic and overmolding. In the end, we reduced the cost of goods by many orders of magnitude by using 20 percent glass-filled PP combined with a soft durometer thermoplastic elastomer (TPE) overmold to eliminate a couple of O-rings. The product requirements called for the part to function after 10 steam sterilization cycles, and this particular part passed without any issues (it probably could have tolerated more). It will be packaged and sold as a disposable, but many European hospitals tend to sterilize anything that still looks usable, so we determined that surviving 10 cycles would be appropriate.

In terms of overmolding, PP is the Holy Grail of materials. Most of the higher-performance and lower-durometer-range TPEs are polypropylene based, which makes it much easier to bond hard materials to soft. For overmolded seals in particular, TPEs unlock design freedom that was thought impossible just a few years ago. Granted, overmolding requires another tool, but with low material costs and the highest-quality design it affords, overmolding pays for itself quickly. I understand that great strides have been made with bonding silicone to PEEK and PPSU, but again, those are more costly materials whose high level of functionality is not always required.

I’ll admit that PP is not all unicorns and rainbows. While it flows like water during molding, sink marks, swirls in the surface finish from glass reinforcement, and shrinkage can be significant challenges. Also, the inherent flexibility of PP needs to be considered when the user’s feel is a high priority, but 20 percent glass-filled is a good compromise between tool life and product rigidity. Heavy walls are another limitation of PP. I worked on ConMed Corporation’s DetachaTip Laparoscopic Instrument not too long ago, and specific sections of that handle were over 0.25 inch thick. We could have “faked” thickness with ribs, but a ribbed part doesn’t always feel or look the same as a solid part. Consequently, we made that handle from injection-molded PPSU.

ConMed DetachaTip Laparoscopic InstrumentIn closing, this is why I love polypropylene:

  • Let’s be honest. It’s cheap!
  • It withstands repeated steam sterilization cycles like many highly engineered plastics.
  • With the right combination of additives, polypropylene can be made strong, and more importantly, stiff.
  • You can overmold directly to it with PP-based TPEs that will also survive steam.
  • Creative designers can work around many of the molding and mechanical performance shortcomings.
  • It’s one of the most widely recycled materials, so it can be used to accommodate sustainability goals. .

Topics: medical device, engineering, Medical Device Development

Health IT +Telehealth Developers: These Users Need Your Help!

Posted by Kristyn Berry on Fri, Oct 30, 2015

The telehealth/health IT industry is in an endless state of innovative disruption, spurred by start-ups, innovators, and technologists rethinking how best to address today’s healthcare needs and improve the patient/doctor experience. In an age when the term “design thinking” has seeped into so many different industries, there is ample opportunity to rethink culture, space, and connectivity and center this on the user experience.

Rethinking telehealth connectivity relates to the redesign of other medical-related technologies as well, such as mHealth and Wearable Health devices. The required connectivity between these products will likely redefine the overarching communication system used to distribute and process the data and resulting insights related to a patient’s health.

This rethinking of culture and space has led to technological advancements in remote patient monitoring, virtual doctor visits, and the increased use of electronic medical records (EMRs). Virtual doctor visits give people living in rural areas access to a wide variety of medical professionals, even though they might be located hundreds of miles from a patient’s residence. And EMRs follow patients throughout their lives — even if they change from one primary care physician to another — making it easy for a physician to access a patient’s medical history.

The growing trend in telehealth has companies introducing products like Salesforce’s Health Cloud, which seeks to make the patient/doctor experience more about “patient relationships, not records,” says Dr. Joshua Newman, chief medical officer and general manager of Salesforce Healthcare and Life Sciences. But when thinking about patient/doctor relationships, it’s important to consider the different types of users who stand to benefit from telehealth technologies, and the important things to consider when developing technologies for these users.

Image source: and veteran populations could greatly benefit from telehealth technologies, considering that they’re located all over the world, in critical situations that place them in physical and psychological danger, and are often put into emergency situations that require immediate point-of-care solutions. A recent article in mHealth News details mHealth and telehealth initiatives that are outlined in the 2016 budget proposal for the Department of Veterans Affairs (VA). More than $1 billion is being put toward these initiatives, many of which focus specifically on mental health treatment, as it is hoped that telehealth systems can help to maintain and improve the treatment of veterans with PTSD and other stress-related conditions. About $30 million is going to interoperability initiatives and $230 million to upgrades to the VA’s EMR system. These upgrades would assist in streamlining the MyVA portal that gives veterans access to VA services from various locations and devices, allowing veterans more involvement in their care and giving medical professionals a better understanding of their needs.

Image source: patients represent another group that can benefit from telehealth technologies, considering that this population often has special healthcare needs that require consultation from specialists who may not be local to where their families live. A report from the American Academy of Pediatrics pointed out that “there is a significant disparity in the geographic distribution of pediatric physicians across the country, resulting in many underserved regions…most commonly found in rural regions, but can include suburban and urban settings.” Telemedicine can offer pediatric physicians the ability to treat and consult with a greater number of patients, resulting in decreased wait times and reducing the need for pediatric patients to travel long distances for treatment.

Image source: patients can benefit from telehealth, especially in the context of home healthcare. An increasing number of seniors are living with chronic diseases and rely on health monitoring devices that are easy and safe to use in the comfort of their own homes. Physicians rely on these devices to collect information that they can view in real time or refer to during an appointment with the patient. Additionally, telehealth technologies like videoconferencing offer physicians the ability to conduct remote-access virtual consultations, creating a huge benefit for older populations with significant mobility challenges. They now have the option of speaking with a doctor from home instead of having to travel to a doctor’s office. The increasing adoption of telehealth systems and home healthcare devices is also driving the need for training in the use of these products, which leads to greater awareness by patients as to the state of their own health.

Image source: wsj.comPhysicians also benefit from technologies like remote patient monitoring and EMRs, and from interactions like virtual patient visits. EMRs enhance the ability of physicians to quickly access patient information from virtually any location. They also promote consistent care compliance by creating a single location from which to retrieve a new patient’s past medical history as the patient is treated among various facilities and by different doctors. This is especially important for patients suffering from chronic conditions. Telehealth technologies also help to reduce the frequency of ER visits, and can free up physicians to devote more time to patients. However, physicians continue to be concerned about the usability aspects of these technologies and the ability of EMRs to achieve interoperability between software platforms. Recent government figures mentioned in an article by CIO show that “48 percent of physicians have adopted EMRs, while electronic records are in place at 59 percent of hospitals.” EMRs should be capable of getting the most meaningful patient information/data to the right people at the right time, and in a perfect world would be able to function seamlessly across hundreds of different organizations.

How can users’ concerns be resolved and their needs incorporated into future telehealth technologies? Here are some suggestions for how developers could address usability concerns:

  • Consider the physical needs and limitations of an aging population and develop technologies that account for their potential auditory/visual/memory/motor impairments and technical experience levels.
  • If technologies are being developed for in-home use, consider the space that a product will require, available power sources, the need for wireless connectivity, etc.
  • Consider the amount of data and information that is presented to the user. For example, a large amount of information may be overwhelming or unnecessary to an elderly user, but may be informative and appreciated by their caretaker.
  • Develop training plans as necessary, keeping your user in mind.
  • Include options that incorporate a multidisciplinary approach for healthcare professionals (HCPs), allowing them to consult other HCPs as they see fit before offering treatment options or making a potential diagnosis.
  • Realize that technologies developed will be accessed by patients with chronic conditions who may require extra assistance utilizing and interacting with the technologies.
  • Physicians naturally seek out technologies that reduce workflow and increase efficiency while giving them confidence that they’re delivering their patients safe, high-quality care. In a TEDMED talk entitled “The Human Factor,” UK physician Pritpal Tamber discusses physicians’ general resistance to change and their feelings of doubt and cautiousness when encountering new technologies. Physicians will be resistant to technologies that are unreliable, increase the steps involved in working with patients, or interfere with their ability to make decisions related to patient treatment.

Topics: mHealth, healthtech, telehealth, health it

Optimizing Partnerships in Medical Product Development

Posted by Art Rousmaniere on Wed, Jul 22, 2015

It’s become critical in today’s medtech landscape for medical device OEMs and startups to work with outside partners when transforming a technology from concept to commercialization. Increased pricing pressures, burdensome government regulations, and swiftly-evolving manufacturing techniques have made outsourcing a critical component of the development process for most medtech companies. According to a study by Grand View Research, the global medical device outsourcing market is expected to reach $50.37 billion by 2020, and outsourcing has helped OEMs reduce the cost of production by approximately 15%.

Outsourcing design and engineering to a development partner, choosing a contract manufacturer (CM) and identifying parts suppliers can add layers of complexity to the product development process, but there are many ways to make these partnerships more efficient.

At the heart of a successful development partnership is effective communication between OEM/Client, Development Partner and Contract Manufacturer.

Be clear about roles, responsibilities, and expectations

As with any team, each member may play either a primary or supporting role at various times in the overall process. Recognizing, defining, and communicating these roles during the development cycle is important for grounding expectations within the team. But it’s also important to:

  • Negotiate support expectations early. CMs and part suppliers often say they want to be involved early in the development process, because leveraging their expertise improves performance and (hopefully) reduces the cost of the final product. But be aware that these partners may not like being pressured with excessive requests for design for manufacturability (DFM) and cost analyses early in the program, as this diverts their resources from more immediate projects. Negotiating expectations in advance is integral to the development direction and helps build a cohesive team.
  • Define who will assemble prototypes within each phase. Early prototypes should be assembled by the development partner because they can more effectively evaluate, debug and improve the design. But we’ve found that it’s beneficial to the program for the CM and development partner to work together when assembling the later-phase prototypes, such as production equivalent units (PEUs) that are intended to fully match the production design.
  • Define who will do the testing. Done correctly, developing a new medical device requires several phases of testing and verification. Any of the partners involved can develop the protocols and perform the tests, but in general, testing that will result in important feedback is best done by the development partner while the more rigorous verification should be done by the CM or client.
  • Define who qualifies suppliers. For larger OEMs, this is typically done internally. For smaller companies and startups who do not have the relevant experience, this can be done by the development partner or the CM. Better CMs will have approved vendor lists (AVLs) that include all of the required manufacturing technologies (e.g., PCB fab, injection molders, etc.), but occasionally a project will require a technology that is new to the CM. This is where the development partner can add value by recommending suppliers.
  • Define who inspects prototype parts. Part inspection is one of those tasks that’s often overlooked during prototyping because everyone on the development team is frantically completing designs and planning for fabrication and assembly. CMs and part suppliers are best equipped to perform inspection and provide detailed reports of production parts. For programs that require any sort of pre-verification in their plans, inspection of prototypes is critical but can take a significant amount of time to do correctly, so this role should be assigned in advance.

Practice constant vigilance to minimize surprises

A huge part of what makes a project successful can be traced to team members who, because they communicated effectively, prevented unexpected issues from having a negative impact on the development schedule. The trick is to find the right balance when planning a communications strategy. A lack of communication will inevitably lead to nasty surprises, but “overcommunicating” – too many e-mails or too many meetings – can negatively affect productivity. Any communications approach should be in place to help all team members do their jobs more effectively.

Other ways to be vigilant include:

  • Don’t underestimate the importance of effective program management. Project leaders working within tight budgets are too often drawn into crisis mode because they’ve mistakenly assumed that all program management was being administered by the client. Diligent project planning needs to be done by all partners.
  • Generate and maintain a master schedule that can be referenced by all partners. There are effective tools for generating a detailed project plan (e.g., Microsoft Project). Smaller projects can use less formal planning tools, such as a spreadsheet. Whichever tool you choose should make it easy for each member to quickly and efficiently see the line items that pertain to them without having to dig through the entire plan. However, be careful of giving too many team members the ability to make edits, as this can complicate the plan and cause confusion among partners.
  • Generate and maintain a cross-functional, open issues tracker and keep it current. The tracker should focus on system-level issues while each partner is focusing on issues that pertain to their core responsibility. This is critical for larger projects and independent teams. Keep the tracker appropriately scaled and of a manageable size. For larger projects, a cross-functional, open-issues tracker can be used that only includes the issues that impact the overall team.
  • Be ready for the unexpected to mitigate development delays. Major project delays can occur where a product suddenly – and unexpectedly – requires significant technological invention during development. Because of the time, effort, and “unknowns” involved, such invention can be difficult to plan around, but experienced development managers know that there will always be the possibility that this additional work is required. However, unexpected project delays more typically come from major shifts in the design direction. Two specific offenders are:
    • Feature creep. All too often, OEMs and start-ups are blamed for piling on new requirements during development, but each team can be guilty of adding new requirements in the name of an improved product, reduced cost, etc. It takes a program manager with a will of iron (and strong negotiating skills) to keep feature creep under control.
    • Risk. The team should generate and maintain a risk tracker that includes any technical or program-related risks that the overall team, especially the client, should be aware of. Setting up a good risk tracker ensures that challenges to the program will be addressed as early as possible. It also ensures that upper management is aware of the risks so that tactical decisions can be made to either accept a risk or make a contingency plan.
    How partners can support each other

    As with any partnership, every member of the team needs to understand how each partner can support the other, but this will depend upon the level of each partner’s expertise. If all partners are exceptionally qualified and experienced in each of their individual roles, this understanding should be in place at the beginning of the program. That being said, it’s always wise to hope for the best, but plan for the worst.

    The client/OEM, Development Partner and CM have inherently different levels of involvement during the product development cycle, but there are areas of overlap where they can support each other.

    Some areas of opportunity include:

    • Minimizing product cost is a team effort: While the contract manufacturer is primarily responsible for determining the product cost, the actions and demands of all partners involved have a direct impact. Ford Motor Company’s long-accepted rule of thumb is that about 80% of the cost of a product is fixed in the first 20% of its development cycle. The client should calculate and provide a product’s target cost to the development partner as early as possible in the development process. Often, smaller OEMs and startups in particular lack the expertise to determine a target cost. In these cases, a development partner with a strong background in bringing products to market (like Farm), can assist by providing estimates to the client to help generate a target cost. A CM can supply even more accurate estimates, but they’ll typically require the design to be fairly well defined.
    • Design for manufacture and assembly (DFMA) to reduce cost is also a team effort. The development partner is responsible for the design of the product, but the CM can play an effective support role during development. An example of this concerns printed circuit board assemblies (PCBA). The development partner may not care if a simple PCBA is 1 or 2 sided or surface-mount-only, but the CM may be tooled for high-speed, surface-mount-only manufacturing. Another example concerns the method of joining plastic parts. CMs typically have process expertise and preferences that the development partner can accommodate, such as screw assembly versus ultrasonic welding versus adhesive bonding. Including the CM in the conversation helps the team choose the most appropriate manufacturing process. The CM can then supply process guidelines to help the development partner complete the design.
    • “Stretching” manufacturing technologies isn’t just for the CM. Most new products can still be made using standard components and manufacturing processes (e.g., simple circuit boards, sheet metal or injected molded plastic parts, etc.) and industry-standard tolerances. But more complex products may require pushing design and manufacturing beyond their “standard” limits (such as by requiring extremely tight tolerances or the inclusion of a new technology). For these more complex projects, a team can still achieve improved product performance, hit cost targets and make deadlines if the development partner and CM work together early in the development cycle.
    • High production volumes require collaboration between development partner and CM. Automated assembly by the CM can be a huge benefit to high-volume production. This can include vision systems and robotic handling and may require the addition of special features to individual parts, such as molded-in fiducials for the vision system or features that a robot can grab. Details like these will require close collaboration between the developer and the CM.

    Beware the gotchas

    We’ve all lived through projects that could have been more successful and then spent hours discussing what we could have done better. Effective development teams take these experiences and apply them to minimize schedule-and budget-busting problems in subsequent projects. Often these problems are caused by putting off “trivial” issues at the beginnning of a project for the sake of focusing on the bigger challenges-procrastination that eventually results in those small challenges ballooning into bigger ones.

    Some examples to watch for:

    • Resist the temptation to build an “over-the-wall” culture. The classic example is delaying the selection of a CM and/or part vendors until after the design is complete under the assumption that bidding out the more fully-resolved design will result in lowest costs. While this could save a few cents on simpler parts, it often results in a design that’s prematurely designated as “complete” but will have to be re-opened for at least minor refinement on the more complex parts.
    • Standards and templates are most effective when used from the start. Examples of this include company-accepted drawing format and specification templates, standard drawing notes, and part numbering schemes. Distribute these administrative assets at the start of the project and you‘ll save time and effort by eliminating duplication of work.
    • Define a fastening hardware strategy that works for each partner. Nobody buys a product because of the fastening hardware, yet inevitably, bills of materials (BOMs) and CAD models require updating in the 11th hour to change the screws from machine to self-tapping, metric to ISO, zinc-plated steel to passivated stainless, or Phillips to Torx. And selecting some specific screw lengths as a baseline in advance of detailed CAD development can reduce the prolifieration of so many hard-to-distinguish lengths that can be cumbersome in manufacturing.
    • Cables and labels are typical “gates” for production. Why? Because they aren’t sexy, so they don’t get the focus they deserve. It’s not uncommon to be frantically specifying and documenting the details of cables and graphic content for labels and printed graphics while the rest of the parts sit in storage at the CM waiting for production. Product packaging is often a “gate” for the same reason.
    Concept-to-product realization projects done by partners who collaborate effectively are much more likely to result in products that meet or exceed the OEM’s goals. OEMs that understand how their partners work and communicate with each other, and that are proactive about engaged planning with those partners, are at the core of an effective partnership. In this era of multiple outsourced partners, project success is all about experience, communication and planning. As Benjamin Franklin said, “If you fail to plan, you are planning to fail.”

Topics: medical product development, medical device outsourcing, Medtech

A Look Inside Healthcare Hackathons: Solving HealthTech Challenges

Posted by Kristyn Berry on Mon, Jun 29, 2015

A few months ago I attended my first hackathon, MIT Hacking Medicine’s Grand Hack 2015. I made a 3-day commitment to immerse myself in a world of healthcare and medicine, amid designers, scientists, engineers, developers, clinicians, entrepreneurs, and business people with varying backgrounds. I call it a “commitment” because I entered a bubble-like microcosm of creative, curiosity-driven minds, some of whose careers put them at the forefront of today’s healthcare challenges, and others who are personally motivated to make a difference in the world of medicine. Some had attended hackathons before, and some were first-timers, but all were there to address user needs and pain points in an effort to solve existing healthtech challenges.

MIT Hacking Medicine’s Grand Hack 2015

Day 1 began on Friday evening. I found myself with 700 other participants, listening to a series of leaders in healthcare and medicine talk about existing challenges. The hackathon is divided into four tracks: Global Health, Primary Care, Telehealth, and Wearables. Despite already choosing to participate in the Wearables track, I was debating my decision by the end of the talks. I hadn’t quite understood the term Telehealth, but I found myself thinking about all the powerful ways healthtech could connect patients and doctors around the world. I was also thinking about how I could make a difference in healthcare on a global level. If you consider all the experiences a patient has while in a typical clinical setting - a doctor’s office; a hospital - it’s interesting to imagine how those experiences could be personalized and improved. After the talks, we broke out into tracks and I decided to move forward with wearables and see where it led me. As the discussion began several people already had healthcare pain points that they wanted to solve. People were given 60 seconds to explain these pain points without focusing on solutions. The purpose of this exercise was to get people thinking about the people affected by the problems first. Some participants had actually experienced the pain points they described and that made the need to solve the problems all the more real. The pain point I pitched involved medication interactions:

People with chronic conditions - particularly psychological conditions - are often on multiple, similar types of medication at the same time. If patients could have a clear, easy way to track which medications are having which effects on their body, both patient and doctor could more effectively address symptoms.

Day 1: MIT Hacking Medicine’s Grand Hack 2015

After about 25 pitches, the people in our track mingled and discussed. There’s no better feeling than putting a very preliminary thought or idea out for discussion, and having people approach you, deeply interested in your idea and wanting to explore it further. After Friday night, it was evident that some people had already identified problems and ways to solve them and were interested in attending the hackathon to recruit people to further develop those solutions.

On Saturday morning, several alumni of the hackathon told personal stories about successful solutions they had pitched the previous year that had become the basis for viable businesses. We were instantly motivated to think about what we wanted to accomplish for the weekend. Many of us focused on winning, convinced they had creative solutions to healthcare’s biggest challenges. Others were just there to have a good time. My reason for attending was to problem solve, brainstorm, and meet new and interesting people from a variety of backgrounds. Possibly the most exciting part about the hackathon was seeing the different cultural backgrounds of the participants. Ten countries were represented, and each country experiences different pain points within healthcare.

MIT Hacking Medicine’s Grand Hack 2015 - Pitches

That morning, attendees presented their pitches within each track one by one. Some pitches had been developed further from the night before and others were entirely new. Afterwards, everyone had the opportunity to further discuss pitches and form into groups. My group was made up of people with backgrounds in ergonomics, UI design, programming, and business. Our solution was focused around people who have habits that they’d like to break, specifically habits characterized as Body-Focused Repetitive Behavior (nail biting, hair pulling, face touching, etc.), because these habits can lead to physiological damage and embarrassment. The idea came from one of our team members who knew a young girl who suffered from an extreme case of trichotillomania (hair pulling). Our team decided to focus on the wider realm of breaking many different types of habits, including hair pulling. During the rest of that day, each team brainstormed solutions to their pain points, exploring how they could use pre-existing technologies (e.g., wearable health devices like Microsoft Band, Jawbone, and Myo Arm Band) to develop their prototypes. In addition to coming up with creative ideas that kept the end user in mind, we also had to generate solutions that would fit within a feasible business model. Throughout the day, our team conducted surveys, interviewed end users, and talked through our ideas with mentors of various backgrounds. Each person used different processes to brainstorm, and together we figured out how to be most effective and cohesive. We accomplished in a day what would usually take a development consultancy weeks.

My Hackathon Team

The last day of the hackathon found the teams from each track excited, bleary-eyed, and bustling. Many had stayed up all night working on their solutions. My team finished up by analyzing our data from the survey responses, nailing down our business model, and organizing our presentation. At the end of the day, each track presented their final output. Our track had developed impressive and disruptive solutions to pain points in diabetes, hospital and patient care, and more, addressing the needs of end users of all ages.

Last Day: MIT Hacking Medicine’s Grand Hack 2015

During the awards ceremony, teams from all tracks squeezed together on the sixth floor of the MIT Media Lab to hear if all their hard work that weekend had paid off. Unfortunately my team was not one of those winners, but everyone who attended was recognized as innovators and creative thinkers. The hackathon had allowed us to explore ideas, take risks and tap incredible resources in our quest to solve healthcare challenges. The event left us with a network of friends and an eagerness to participate in future hackathons.

Topics: healthtech, user needs research, wearable health

Wearables and mHealth: New FDA Draft Guidance on Low-Risk General Wellness Products

Posted by Kristyn Berry on Tue, Mar 31, 2015

Wearables and mHealth

One of the most widely discussed trends that has emerged within the medical device industry is the development of wellness and health-focused wearable devices and mobile health applications. These devices and related apps, often grouped under the term mHealth, can perform a wide range of functions that are becoming increasingly important to users. These include tracking daily exercise, recording food intake, monitoring vital signs, and delivering critical data to healthcare practitioners who may be providing remote diagnosis and treatment, or to researchers who are conducting clinical studies. Many of the newest mHealth products are wearable, providing the user with a convenient platform with which to quickly view information and download that information to other cloud-connected devices and social media. With the increasing development of wearables that are not only informative but also communicate a premium level of brand quality, it’s doubtful that this trend is a fad that will eventually fade away. There is simply too much data-gathering power appearing on users’ wrists. The growth in wearable devices and mHealth applications will surely lead to disruptive, innovative and out-of-the-box thinking that will ultimately transform the healthcare industry.

Some of the world’s largest technology companies - Apple, Samsung, Google, Sony, and Lenovo - have already introduced products and apps to the ever-expanding wearable mHealth market. Devices such as the Apple Watch, the Misfit Shine, and the Fitbit have the ability to track distance walked or run, measure calories burned, monitor sleep, measure blood pressure, and more. But an exciting addition to these so-called fitness trackers are several wearables that are directly involved with informing healthcare decisions. These products include Embrace (monitors epileptic seizures), the Neumitra biowatch (measures and manages brain health), and Imec’s smart ECG necklace (aimed at detecting heart arrhythmias). The Embrace device measures physiological signals such as sleep patterns, physical activity, and stress levels. But what sets Embrace apart from a wearable like Fitbit, is that it goes one step further by being associated with a specific disease - epilepsy. The company making the Embrace product states it can detect seizures and can therefore save the lives of people suffering from epilepsy. The FDA considers their marketing verbiage a “claim,” indicating that the device treats or diagnoses a chronic disease or condition. And this claim is exactly why the FDA is particularly interested in a device like Embrace as opposed to a device like the Fitbit.

The FDA recently released a draft guidance entitled “General Wellness: Policy for Low Risk Devices” that carefully outlines its new policy on assessing wellness products and how that assessment is determined by its definitions of “general wellness” and “low risk.” These products can include video games, software programs, exercise equipment, and audio recordings. The FDA, matching its policies to the rising interests in wellness products, has come up with a specific formula that companies can use to figure out whether or not their product qualifies as a general wellness, low risk device.

Categorizing General Wellness

The FDA has defined overall general wellness products as those that are intended to promote or maintain general wellness, and those that present minimal or low risk to user safety. The FDA has defined the parameters of general wellness products as fitting into one of two possible categories:

(1) An intended use that relates to maintaining or encouraging a general state of health or a healthy activity


(2) An intended use claim that associates the role of healthy lifestyle with helping to reduce the risk or impact of certain chronic diseases or conditions and where it is well understood and accepted that healthy lifestyle choices may play an important role in health outcomes for the disease or condition.

The big difference between the two is that one singularly relates to overall general wellness, whereas the other relates in some way to a specific chronic disease or disorder. In the first category, the “general state of health or healthy activity” includes physical fitness, weight management, relaxation or stress management, mental acuity, self-esteem (for example, a device that has a cosmetic function only making claims to impact self-esteem), sleep management, or sexual function. Products like the Fitbit clearly encourage physical fitness by motivating owners of the wearable to alter physical activity in some way. Fitbit also tracks calories burned, maintains weight management, and tracks sleeping patterns, which all fall into this first category. Products that claim to treat, diagnose, or restore structure/function impaired due to a disease, do not fall into this category.


For the second disease-related category, devices are further categorized into one of these two subcategories:

(1) Intended uses to promote, track, and/or encourage choice(s), which, as part of a healthy lifestyle, may help to reduce the risk of certain chronic diseases or conditions.


(2) Intended uses to promote, track, and/or encourage choice(s) which, as part of a healthy lifestyle, may help living well with certain chronic diseases or conditions.

Neither category claims that the promotion or encouragement of certain choices will absolutely affect a certain chronic disease or condition. Instead, they say that they “may” or can potentially affect a disease or condition. The single difference between these two categories is that the first speaks to a person who does not already have the mentioned chronic disease or condition, whereas the second speaks to a person who already has the chronic disease or condition. For example, a product that falls into the first category can promote physical activity, which, as part of a healthy lifestyle, may help lower the risk of high blood pressure. A product that falls into the second category can track caloric intake and help maintain a healthy weight. Healthy weight may help living well with high blood pressure.

It is very important that these disease-related general wellness claims come from a deep understanding and general acceptance that the product does indeed lower risks or has an impact on the chronic disease or condition mentioned. This “proof” can originate from science journal publications, for example. The guidance particularly points out several diseases that the product may claim to lower risks for or have an impact on; high blood pressure, type 2 diabetes, and heart disease. For example, by providing calorie and exercise tracking - both of which can help support a healthier lifestyle - it’s clear that Fitbit can reduce the health risks for users living with these conditions.

What constitutes “low risk”?

If the product falls into the first and/or second categories of “general wellness” within the FDA draft guidance, there is an additional "low risk" criterion the device must meet before qualifying as a general wellness product. If the product is in some way invasive, involves an intervention or technology that may pose a risk to a user’s safety if controls are not provided (risk from lasers, radiation exposure, or implants), raises new questions about usability, OR raises questions of biocompatibility, the device is NOT low risk. To illustrate this, the guidance uses as an example a product that is intended to mechanically exfoliate the face, hands, and feet to make the skin smoother and softer. Since this product’s claim does not refer to a specific disease or medical condition, but instead addresses self-esteem, it can be considered a general wellness product. But is the product low risk? The answer is yes, because the product only exfoliates the face and is not considered “invasive” since it does not penetrate the outermost layer of the skin. However, if the product were to deliver a chemical that entered through that layer of skin, then it would be considered invasive and therefore would not be low risk.

Encouraging the Wearable Trend

Throughout the FDA draft guidance, words like “intended use” and “claims” stand out as possible ways to make or break a device in terms of whether it will be considered as a general wellness device by the FDA. Manufacturers must carefully consider their messaging when developing marketing initiatives for their wearable health device and related mobile health apps. It’s essential that companies don’t overstate their product’s capabilities and instead use this draft guidance as a tool that will help get new mHealth products to market. As the wearable technology category explodes with new products and technologies, the consumer healthcare field can profoundly benefit from the development of devices like Embrace and other disease-related devices that can potentially save lives and help people living with certain medical conditions maintain a healthier lifestyle.

Topics: medical device, mHealth, wearable health