Isha Sharma
Isha Sharma

A phone update can be routine for most people. For someone relying on a digital application to monitor glucose or support insulin therapy, it can create a much more consequential problem if the software suddenly stops working as expected. Isha Sharma deals with that gap between consumer technology and medical-device reliability as a program manager at MiniMed, formerly the Medtronic diabetes business. Her work spans the development and global launch of patient-facing digital health applications used across 120 countries.

The applications sit inside a larger diabetes-care system in which patients, physicians, and caregivers depend on timely information. Sharma has worked on products including MiniMed Mobile™, Guardian App™, CareLink Connect™, Simplera™, CGM Clinical App™, and firmware-over-the-air functionality that was later integrated into MiniMed Mobile™. Some of the applications help patients monitor glucose and therapy, while others allow clinicians or caregivers to review health information. All the above-listed products are prescription-based, which places their development inside the additional constraints that come with regulated medical technology.

"The technology can work perfectly in development and still does not work on the phone they actually own or in the environment where they actually use it," Sharma said. Her role begins well before launch. She works with internal cross-functional teams to establish requirements, coordinates product development, and helps carry applications through the steps needed for commercial release. This puts her between technical development and the realities that can determine whether a product remains usable once it leaves the development environment.

The global scale makes those realities harder to separate from the product itself. Sharma's work has to account for differences in infrastructure, connectivity, languages, regulatory requirements, and levels of digital access across markets. A feature that behaves reliably under one set of conditions may need additional planning before it can be introduced somewhere with different devices or network limitations. For Sharma, those variations are part of product development, not problems to be addressed after launch.

Compatibility is one of the clearest examples. Medical devices may remain in use for years, while smartphones and operating systems change much faster. A patient may update a phone without realizing the change could affect an application connected to glucose monitoring or insulin management. Sharma's work includes helping teams anticipate those changes so a patient does not lose access to information because the consumer technology around the medical system has moved forward.

Remote updates create a related challenge. Improving a medical device once meant that certain changes required replacement or more direct intervention. Firmware delivered over the air allows improvements to reach patients without the same disruption, but it also requires careful coordination around validation, compatibility, and release readiness. Sharma has worked on firmware-over-the-air functionality that is now integrated into MiniMed Mobile™, connecting software delivery with the longer life cycle of the medical devices patients depend on.

That work requires her to operate across functions that often have different priorities. Engineering may be focused on technical feasibility, while regulatory teams are looking at compliance requirements and clinical teams are considering patient safety and evidence. Quality teams and Marketing introduce their own constraints. Sharma's job is to understand enough of each function to identify where those priorities may collide before the collision becomes a launch problem.

"I lead across functions without authority over all of them," Sharma said. "That means I have to understand why each group is pushing for what it needs and find a path that keeps the product moving without ignoring the constraints that matter." She describes that coordination as one of the hardest parts of the work because deadlines, scope changes, and patient needs do not always line up neatly with organizational boundaries.

Some of Sharma's product-development work happens before a patient ever sees the resulting technology. She has worked on building tools such as CGM Clinical App™, which is intended for use in clinical research only. That assignment required the same kind of coordination between technical development and the requirements that determine whether a medical technology can move forward. It adds another layer to her role, which extends from patient-facing commercial applications to the supporting work designed for clinical study purposes.

That distinction matters as diabetes technology becomes more connected. Continuous glucose monitors, pumps, connected applications, and remote software functions increasingly operate as parts of the same therapy environment. Each connection can make care more useful, but it also creates another point where compatibility, connectivity, or validation can affect the patient experience. The technical product and the delivery system around it are becoming harder to separate.

Sharma's role sits inside that connective layer. She is not developing the underlying therapy itself. She is responsible for helping the teams around that therapy turn requirements into products that can survive development, validation, launch, and continued use across markets. The work is less visible than a new sensor or algorithm, but it determines whether those technologies remain accessible after they leave the lab.

"The question I keep coming back to is how the science actually reaches someone," Sharma said. "A good technology is only the beginning. Someone still has to make sure it works in the real world, for the patient who is actually going to depend on it."

Across 120 countries, that question becomes practical rather than philosophical. Sharma's work on digital-health applications is measured in products that have moved through development and into patient use. Between those two points are requirements, regulatory constraints, compatibility decisions, and launch details that rarely attract attention. They are also the decisions that determine whether a working technology becomes one a patient can actually use.