At a Glance: Today's issue dives into the FDA's game changing new guidance on wellness and clinical decision support software, explaining how the line between a regulated device and an app has shifted. We also cover Medtronic's newly cleared smart insulin pen system and a wild new ultrasonic sensor for cuffless blood pressure monitoring. The theme this week is navigating the ever changing regulatory landscape.

RECALL ANALYSIS

FDA Just Redrew the Line Between Wellness App and Medical Device

Here’s a regulatory curveball you probably weren’t expecting: the FDA just made it easier for some digital health products to *not* be considered medical devices. In a surprise move, the agency released final guidance that clarifies its enforcement discretion for General Wellness and Clinical Decision Support (CDS) software. And yes, you read that right, they're actually loosening the reins a bit.

This isn't just some minor wording tweak. The updates provide a clearer, and in some cases more permissive, framework for products that sit on the fuzzy border of consumer wellness and clinical care. For any engineer working on wearables or healthcare software, this is required reading.

What the Guidance Update Says

The FDA's update maintains the existing two factor framework for general wellness products: they must be for general wellness use and present a low risk to users. But the big news is a new section specifically addressing non invasive sensors that estimate physiological parameters like blood pressure, SpO2, or even blood glucose. The guidance suggests these can fall under enforcement discretion as long as they meet a strict set of criteria.

The key is that the device can't be intended for diagnosis or treatment, can't substitute for a cleared medical device, and can't prompt specific clinical actions. It can tell a user that a value is outside a normal wellness range, but it can't say “your blood pressure is high” or identify a specific disease. It's a fine line, but it's a much clearer line than we had before.

For Clinical Decision Support (CDS) software, the change is even more significant. Previously, if your software gave a doctor a single, specific recommendation, it was almost certainly a medical device. The new guidance says that the FDA will now exercise enforcement discretion for single output CDS functions, provided the software meets all the other criteria for being a non device CDS. This is a huge shift for software in fields where a recommended treatment is already well established in clinical practice.

What This Means for Engineers

Remember the FDA's 2025 warning letter to WHOOP over its blood pressure feature? The agency argued that real time blood pressure readings are “inherently associated with the diagnosis of hypo and hypertension.” But the new guidance includes an example of a wrist worn product measuring blood pressure that *would* be subject to enforcement discretion. This suggests that context and claims are now king. As long as you frame the data for wellness and avoid diagnostic language, you have a path.

The CDS update opens a new pathway to market for many risk prediction and treatment planning tools. Think about software that recommends a specific antibiotic based on local resistance patterns or a cardiology tool that suggests a standard of care treatment. A year ago, that single recommendation would have made it a regulated device. Today, as long as the doctor can review the basis for the recommendation, it might not be.

But here's the catch: the guidance puts a heavy emphasis on avoiding “automation bias,” especially in time critical situations. If your software is used for urgent decisions where a doctor is more likely to just trust the output without thinking, the FDA will still be concerned. Your UI and workflow design have to actively encourage independent review by the healthcare provider.

Regulatory & Standards Context

The legal basis for the CDS changes comes from the Federal Food, Drug, and Cosmetic Act, specifically section 520(o)(1)(E). This section defines what types of software are *not* considered a medical device. The fourth criterion, which requires that the software allows the healthcare provider to independently review the basis for the recommendations, is the one the FDA is now leaning on heavily.

This entire framework operates under the principle of “enforcement discretion.” This doesn't mean these products are approved or cleared; it means the FDA is publicly stating it will not expend its resources to enforce device regulations on them as long as they meet the specified criteria. Step over that line with your marketing claims or features, and that discretion vanishes instantly. Your claims in labeling, advertising, and on your website are the primary evidence the FDA will use to determine your product's intended use.

Design Playbook - Learning from the Event

Audit: Do your marketing claims align with a general wellness intended use?

Scrub every word on your website, app store listing, and user manual. Remove any language that references specific diseases, diagnostic thresholds, or treatment. Replace phrases like “clinically accurate” with “wellness tracking” or “lifestyle insights.” This is now the most important factor in staying on the right side of the line.

Check: Does your CDS software clearly explain its logic to the user?

Criterion 4 of the non device CDS rule is non negotiable. You must provide the “why” behind any recommendation. This could mean displaying the relevant clinical guidelines, source data, or the specific patient parameters that led to the output. Don't bury this information behind a help menu; it needs to be part of the primary workflow.

Audit: Could your single output CDS tool now be considered a non device?

If you previously shelved a project or went through a lengthy regulatory process because your software gave a single, direct recommendation, it's time to re-evaluate. Review the new guidance examples. If your tool supports a well established clinical practice and meets the other three criteria, you may have a much faster path to market.

Check: Does your wearable's notification system avoid giving medical advice?

A notification can suggest a user might want to consult a professional, but it cannot be an alarm that directs medical management. For example, “Your heart rate has been elevated for an extended period” is likely okay. “Warning: Possible Atrial Fibrillation Detected” is not. The difference is subtle but critical.

RECALL ANALYSIS

Your Fitness Tracker's New Superpower? Avoiding FDA Regulation

Ever wonder how a smartwatch can get away with estimating your blood pressure or oxygen saturation without being a full blown medical device? The FDA just clarified the rules in its updated “General Wellness: Policy for Low Risk Devices” guidance, and it’s a big deal for anyone engineering wearable tech.

The agency is signaling a more flexible approach, officially recognizing that certain non invasive physiological measurements can be treated as general wellness features, as long as they stay in their lane.

What the Guidance Clarifies for Wearables

The core of the update is about physiological sensors. The FDA now provides concrete examples of features that can qualify for enforcement discretion. This includes wrist worn products that track metrics like pulse rate, sleep quality, and yes, even estimated blood pressure. It also covers wearables that provide blood glucose information to help non diabetics understand nutritional impacts.

But there's a catch, and it's a big one. To remain a general wellness device, your product must be non invasive. The guidance gives a clear example: a continuous glucose monitor that uses “minimally invasive microneedle technology” is still considered invasive because it penetrates the skin. Even if it’s marketed only for wellness, that physical action disqualifies it from this policy.

The Fine Line in Marketing

As always, it all comes down to your claims. The FDA is practically giving you a playbook on what to say and what to avoid. Positioning your device’s output as “wellness insights,” “recovery support,” or “lifestyle tracking” is the safe zone. The danger zone is using language that implies clinical grade accuracy, guides therapy changes, or references disease management.

You absolutely cannot make claims that your wellness device can substitute for an FDA cleared medical device. Any comparative or superiority claims are a red flag that will immediately move your product into the regulated medical device category. It's a delicate balancing act between compelling marketing and regulatory compliance.

Regulatory & Standards Context

This policy all hinges on the FDA's two part test for a general wellness product. First, it must have an intended use related to a healthy lifestyle, like weight management, fitness, or sleep quality. Second, it must present a low risk to the user. The updated guidance doesn't change this fundamental framework, but it does provide much needed clarity on what “low risk” means in the context of modern wearables.

The exclusion of anything invasive is a critical interpretation of the “low risk” prong. The FDA defines invasive as piercing or penetrating the skin or mucous membranes. This creates a bright line rule that engineers can design around. If your sensor breaks the skin, even slightly, you should assume you are building a medical device and plan accordingly.

Design Playbook - Learning from the Event

Check: Is your product labeling completely free of comparisons to FDA cleared devices?

Review all user facing materials. If you have a sentence that says your heart rate feature is “as accurate as a hospital monitor,” delete it immediately. Such claims are an explicit signal to the FDA that you intend for your product to be used for medical purposes.

Audit: Map every user facing metric and notification. Does any of them imply a specific disease state?

Go through your entire app's user interface. Does a low SpO2 reading trigger a red banner that says “Warning: Hypoxia Alert”? That crosses the line. Instead, a notification should be framed neutrally, such as “Oxygen saturation is below your typical range.”

Check: Does your sensor break the skin in any way?

If the answer is yes, you are almost certainly building a medical device, not a general wellness product. This applies to microneedles, probes, or any other feature that penetrates the stratum corneum. This single factor can determine your entire regulatory strategy.

Audit: Does your app's UI present data in a way that mimics a clinical dashboard?

Even if your text claims are compliant, a user interface that looks identical to a critical care monitor could be interpreted as implying a medical use. Think about your design language. Is it geared toward a consumer tracking fitness, or a clinician diagnosing a condition? The distinction matters.

DIGITAL HEALTH

Medtronic Connects the Dots Between Smart Pens and CGM Data

For millions of people with diabetes on multiple daily injections (MDI), juggling carb counts, insulin doses, and glucose readings is a relentless mental burden. Medtronic just got a 510(k) clearance for its MiniMed Go system, which aims to automate that cognitive load by integrating a smart pen and a CGM into a single app.

This isn't just about showing two numbers on one screen. The real engineering work here is in the software that turns raw data into actionable insights, like preventing a missed mealtime dose.

What the 510(k) Clearance Covers

The MiniMed Go is a classic example of a system of systems. It combines three components: Medtronic's own InPen, a Bluetooth enabled smart insulin pen; the Instinct sensor, a continuous glucose monitor made by Abbott; and the MiniMed Go mobile app, which serves as the brain of the operation.

The app pulls in dose information from the pen and real time glucose data from the sensor. By fusing these two data streams, it can offer features that neither device could provide alone. According to the press release, this includes missed dose alerts, a dose calculator, and guidance if a user miscalculates a dose. It's this intelligent layer of software that makes the system powerful.

The Core Engineering Challenge: Data Fusion and Trust

The fundamental challenge here is data integration and interpretation. You have two independent, wireless hardware devices from two different manufacturers that must reliably feed data to a central software hub. The system has to be robust to connection drops, data synchronization errors, and conflicting timestamps.

But the real trick is building algorithms that users can trust with their health. A “missed dose” alert is a great example. To generate that alert, the software needs to correlate a lack of a recorded bolus from the pen with a rising glucose trend from the CGM, likely contextualized with the time of day. A false positive (alerting when a dose was taken) erodes user trust. A false negative (failing to alert when a dose was missed) is a direct safety risk.

Regulatory & Standards Context

Because the MiniMed Go system provides “action oriented guidance” and dose calculations, it is clearly a regulated medical device, hence the 510(k) clearance. The software at the heart of this system would be subject to IEC 62304, the standard for medical device software lifecycle processes. This requires rigorous documentation, risk management, and verification and validation for every line of code.

When you integrate third party hardware, like the Abbott sensor, your risk management file (as required by ISO 14971) has to account for the failure modes of that component. You're responsible for the safety and effectiveness of the entire system, even the parts you don't manufacture. This often involves detailed interface specifications and data sharing agreements between the companies to ensure interoperability and reliability.

Design Playbook - Learning from the Event

Audit: If your system uses third party hardware, does your risk analysis cover their failure modes?

You can't just assume the third party component will work perfectly. Your FMEA needs to include scenarios like “CGM provides inaccurate data,” “Bluetooth connection to pen drops mid transmission,” or “Sensor data is delayed.” Then, you must design mitigations in your own software to handle these events gracefully.

Check: Is your dose calculator's logic bulletproof and traceable?

Any algorithm that calculates a drug dose is a high risk function. The logic must be based on established clinical guidelines and validated against a massive set of test cases. Every requirement for the calculator must be traceable from the clinical input to the software code and finally to the test that verifies it.

Audit: How do you validate your system's alerts?

For an alert like “missed dose,” you need a robust validation strategy. This involves creating simulated data sets representing various user behaviors and physiological responses. You must prove with data that your system achieves a very high sensitivity (catching true misses) and specificity (avoiding false alarms).

Check: Is the data flow between components secure and reliable?

What happens if the Bluetooth connection between the pen and the phone is interrupted? Does the dose information get stored and retransmitted later? You need to define and test the behavior for every possible communication failure to ensure data integrity. A lost dose record is a potential safety issue.

DIGITAL HEALTH

Beyond the Cuff: Ultrasonic Sensors Could Revolutionize BP Monitoring

That familiar, tightening squeeze from a blood pressure cuff might be on its way out. A new research paper from Korea's Institute of Machinery and Materials details a skin attachable ultrasonic sensor that offers a glimpse into a future of continuous, cuffless blood pressure monitoring.

While many smartwatches attempt to estimate blood pressure optically, this approach uses ultrasound to measure the physical change in a blood vessel's diameter, which is a more direct way to assess pressure.

How the Technology Works

This isn't your standard, bulky ultrasound probe. The researchers developed a tiny, flexible 5 by 4 array of ultrasonic transducers on a polyimide substrate. The entire sensor is less than 0.5 mm thick and weighs under a gram. When attached to the skin, it sends ultrasonic beams into the underlying tissue, detects the echoes reflected from the vessel walls, and calculates the change in diameter as blood pulses through.

By measuring the vessel's diameter at its most expanded (systolic) and contracted (diastolic) states, the system can calculate the blood pressure. The key is that it's measuring a direct physical parameter, unlike optical photoplethysmography (PPG) methods which infer pressure changes from blood flow and are susceptible to things like skin tone and ambient light.

The Key Manufacturing Innovation

So, how do you build a high performance sensor that's also flexible and wearable? That's the most clever part of this research. The team used high performance PMN PT single crystal piezoelectric composites, which are great at generating ultrasound but are sensitive to heat. Standard manufacturing processes would destroy their piezoelectric properties.

Their solution was a dual side, low temperature soldering process using a tin bismuth (SnBi) solder. This technique allows them to bond the sensitive crystals to the flexible substrate at under 150°C, preserving their performance. It's a classic materials science and manufacturing solution to an advanced engineering problem, enabling a device that is both powerful and practical for wearable applications.

Regulatory & Standards Context

This is still a research project, not a commercial product. However, the researchers are clearly thinking ahead to the regulatory pathway. They specifically mention validating their sensor's accuracy against the AAMI (Association for the Advancement of Medical Instrumentation) clinical standard, which allows for a mean error of ±5 mmHg. They report an error of ±4 mmHg, showing they're already building toward a premarket submission.

Any future device based on this technology would likely need to conform to standards like AAMI BP22, “Blood pressure measuring devices,” to demonstrate accuracy and reliability. Proving that the cuffless measurement correlates strongly with the gold standard cuff based measurement across a diverse patient population would be the biggest hurdle to getting FDA clearance.

Design Playbook - Learning from the Event

Check: For any novel sensor, are you validating against an established gold standard?

This research team didn't just invent a sensor; they immediately tested it against a vascular phantom and benchmarked its accuracy against the relevant AAMI clinical standard. If you're developing a new measurement technology, your first step should be to identify the existing standard and design your validation plan to meet or exceed it.

Audit: What is the biggest manufacturing risk in your design?

For this team, the risk was thermal depolarization of their piezoelectric material. They identified it early and developed a novel low temperature soldering process to mitigate it. You need to ask what single process step, if it fails, would ruin your device's performance, and then focus your energy on de risking it.

Check: If you're building a wearable, have you solved for conformal skin contact?

A sensor is useless if it doesn't make good, consistent contact with the body. This team used a flexible polyimide substrate and a Parylene C encapsulation layer to ensure the sensor could bend and adhere to the skin's surface without losing performance. This mechanical and materials engineering is just as important as the electronics.

Audit: Does your design rely on a novel material or process?

Using advanced materials like PMN PT single crystals gives you a performance edge, but it can be a supply chain nightmare. If your design depends on something that isn't a commodity component, you need to investigate scalability, cost, and second sourcing options long before you get to manufacturing.