Engineering Better Diabetes Care

Anand Iyer is a doctor, but he isn’t your typical health care specialist. With a PhD in electrical and computer engineering and an MBA, he represents the leading edge of new, technology-driven healthcare that will define the 21^st century.

As chief strategy officer for WellDoc, Iyer and his team developed the WellDoc BlueStar mobile app, a “digital therapeutic” for Type II diabetes. He will be discussing WellDoc’s research at this year’s Medical Design & Manufacturing Expo event.

What’s so special about a healthcare app?

BlueStar is one of the first mobile apps that is cleared by the FDA, can be prescribed by medical doctors and can be approved by insurance. It’s not a drug, but physicians can use it like one in order to help manage their patients’ Type II diabetes.

This is an unusual application for wireless technology, but Iyer notes that treatment modalities through computer code are steadily evolving

“I spent 18 years in wireless and helped build the telematics and wireless industries. In the meantime, I developed Type 2 diabetes myself and joined WellDoc in 2007. We were the first to develop software like developing a drug,” said Iyer.

“We did clinical trials, and published in peer-reviewed journals just like a pharmaceutical company would. We achieved FDA clearance, the first real-time coaching mobile app to do so. It actually carries a drug code, so to activate the app once you’ve downloaded it, you may need a prescription from your doctor. I’m involved, along with the FDA, in an organization called the IMDRF (the International Medical Device Regulators Forum) and we recently released a document about what developers need to do differently to create software that is treated as a medical device.”

Like any modern consumer product, widely used apps need to be engineered for both form and function. And when healthcare is involved, quality and patient safety take center stage.

“There are several factors involved. It’s essential to have a quality management system, just like any pharmaceutical or medical device company. Processes like ISO and CMMI are common to software development, but in addition it’s important to think of quality in terms of defect management and patient safety,” Iyer said.

“The patient safety aspect makes it necessary to add well-documented traceability throughout the test program, as well as a system to take corrective and preventive actions (CAPA) and handle potential recalls. It’s similar to manufacturing; but in addition to product safety, we consider patient safety,” he added.

Risk management is central to medical software development. But risk is measured differently for a bridge designer, an aerospace engineer and a software developer. How does a coder measure risk in the medical sector?

“It’s a very pertinent question,” said Iyer, adding, how does one measure safety and risk in software? It’s the classic failure mode effects analysis, FMEA. You look at the probability of a risk occurring to the patient, and the severity of the event should the risk occur. It’s the product of the two that matters. FMEA analysis helps stratify the risk to the patient. The medical device industry has various classes of devices, but it’s up to the manufacturer to determine in which classification the device fits. The FDA monitors and guides this process closely.”

In traditional manufacturing, the customer defines acceptable quality and mean time between failures. There are standards bodies such as Underwriters Laboratories, but it’s typical to engineer for safety according to industry norms.

Usually, this limits manufacturers’ product liability. Zero defects are always the goal, but this is seldom achieved in production. Can medical devices operate this way?

According to Iyer, this process operates differently due to the nature of the risk in each treatment modality. “You can still theoretically have a product that has defects in the software, provided you have a documented process that can be audited by the FDA and a process that shows how to manage a risk should failure occur. It’s different for a disease like diabetes compared to, say, a heart pacemaker. While everyone shoots for zero defects, there’s no specific target value of zero.”

One way to minimize risk is to engineer redundancy and durability into the product at the design stage. Can you over-engineer for medical software in the same way a civil engineer would for a bridge?

Anand Iyer is certain: “Of course you can. That’s the approach we took. For example, if a patient uses a blood glucose meter to test their sugar, they lance their finger and a meter delivers a number. They could type in a value, say 65 mg/dL, into the application. But what if that number was suspect? We asked ourselves,  ‘what if they type the value incorrectly?’”

“We decided to have the app ask the user if the value is correct, or if it detects an implausible number. Then there’s the emerging adoption of low-energy Bluetooth. By reading directly from the glucose meter, we could remove human error entirely, removing the human-induced failure pathway. If you over-engineer too much, however, the device becomes too inconvenient to use and patient stops using it. The tension is between over engineering for safety and delivering a good user experience. It’s about developing the right balance.”

For traditional players in the medical space such as pharmaceutical companies, it’s all about extensive product safety and efficacy testing, followed by low-cost manufacturing.

Medical software is similar, except in one crucial respect: security. Tamper-evident packaging is a straightforward mechanical solution to security concerns in the pharmaceutical industry, but connected wireless devices are orders of magnitude more difficult to protect against threats such as cyber security hackers. 

The consequences of failure can be just as severe with software as with a physical product. Could this happen?

“Unless you have the proper security fabric built into these things, absolutely it could happen,” declared Iyer:  “Imagine if an app was controlling an insulin pump. Hacking this system could change the dosing and put the patient at real medical risk. One of the areas that the NIST is getting involved with the FDA, is how to plug the current knowledge base in cyber security into the system. In the physical world, if you’re FedEx, for example, you can control your entire supply chain to keep it secure. When end-users bring their own devices, how do you secure it? How far can the FDA enforce security measures to avoid cyber attacks in this space? It’s a very pertinent question.”

Making a secure app that delivers tangible patient benefits, along with ease-of-use, isn’t easy.

“The user experience and security is built-in from the beginning,” stated Iyer. “It’s constructed at the data layer, the logic layer and also in the user interface layer. We think about security procedures while we’re building the application. It makes it a little more top-heavy, and it can even affect the user experience, but from a patient-safety standpoint it is the only way to avoid malicious use of the product. It’s very important.”

Convergence in technology between disciplines in the 21^st century means that engineers such as Anand Iyer at WellDoc can take formerly non-medical technologies, such as smart phones and coded apps, and develop them into practical medical devices. As Iyer stated, “electrical engineering has come a long way from electromagnetism and copper.”

Anand Iyer will deliver a presentation about the WellDoc BlueStar technology at the 2016 Medical Design and Manufacturing East Conference on Wednesday, June 15 at the Jacob K. Javits Center in New York, NY. His case study is among many high-value sources of information and engineering experience at MD&M East, which runs June 14-16, 2016.

The Medical Design and Manufacturing East Conference has sponsored this post. It had no editorial input into this post. All opinions are mine. --James Anderton