Want signal? We need more noise (more examples to address the quiet bottleneck)

April 21, 2026 by Dana Lewis

Note: I’m assuming if you are reading this post that you’ve first read this post, summarizing the concept. The below is a companion piece with some expanded details about the concepts and more examples of how I think addressing this bottleneck will help make a difference.

—

You might hold the perspective that in the growing era of AI, there’s too much noise already. Slopocalypse. (Side note: this entire post, and my other post, was written by me, a human.) That’s not the biggest problem in healthcare, though: in both research and clinical care, so much critical data is simply not collected. We are missing sooooo much important data. Some of this is an artifact of past clinical trial design and how it was hard to collect or analyze or store the data; there were less established norms around data re-use; and some of it is a “collect the bare minimum to study the endpoints because that’s all we are supposed to do” phenomenon.

Nowadays, we should be thinking about how to make data and insights from clinical work and research available to AI, too, because AI will increasingly be used by humans to sort through what is known and where the opportunities are, plus make cross-domain connections that humans have been missing. And we need to be thinking about whether the incentives are set up correctly (spoiler: they’re not) to make sure all available data is able to be collected and shared or at least stored for humans and AI to have access to for future insight. What is studied is also ‘what is able to be funded’, which is disproportionately things that come to the commercial market eventually after regulatory approval.)

“But what’s the point?” you ask. “If no one is looking at the data from this study, why collect it?” Because the way we design studies – to answer a very limited-scope question, i.e. safety and efficacy for labeling claims and regulatory approval – is very different than the studies we need around optimizing and personalizing treatments. If you look at really large populations of people accessing a treatment – think GLP-1 RA injectables, for example – you eventually start to see follow-on studies around optimization and different titration recommendations. But most diseases and most treatments aren’t for a population even 1/10th the size of people accessing those meds. So those studies don’t get done. Doctors don’t necessarily pay attention to this; patients may or may not report relevant data about this back to the doctor (and again even if they do: doctors don’t mentally or physically store this data, often); and the signal is missed because we don’t capture this ‘noise’.

This means people with rare diseases, undiagnosed diseases, atypical or seronegative diseases, unusual responses to treatments, multiple conditions (comorbidities), or any other scenario that results in them being part of a small population and where customizing and individualizing their care is VERY important…they have no evidence-based guidance. Clinicians do the best they can to interpret in the absence of evidence or guidelines, but no wonder patients often turn to LLMs (AI) for additional input and contextualization and discussion of the tradeoffs and pros and cons of different approaches.

We have to: the best available human (our clinicians) may not have the relevant expertise; or they may not be available at all; or they may be biased (even subconsciously) or forgetful of critical details or not up to date on the latest evidence; or they may be faced with a truly novel situation and they don’t have the skills to address it because they’re used to cookie-cutter standardized cases. This is not a dig at clinicians, but I recognize that we now have tools that can address some of the existing flaws in our human-based healthcare system. I keep talking about how we need to recognize that evaluations of AI in healthcare shouldn’t treat the status quo as the baseline to defend, because the status quo itself has problems, as I just described.

And AI has some of the same problems. (Except for the ‘not available’ part, unless you consider the lower-utility free access models to mean that the more advanced, thinking-based models are ‘not available’ because of cost access barriers). An AI may not have any training data on a rare disease… because nothing exists. It may drop information out of the context window, and we may not realize that this has happened (i.e., it ‘forgets’ something). Usually these are critiques of AI, juxtaposed against the implication that humans are better. But notice that these critiques are the same of humans, too! This happens all the time with human clinicians in healthcare. A human can’t make decisions on data that doesn’t exist in the world, either!

So…how do we “fix” AI? Or, how do we fix human healthcare? We should be asking BOTH questions. Maybe the answer is the same: increase the noise so we increase the signal. Argue about the ratio later (of signal:noise), but increase the amount of everything first. That is most important.

How might we do this? I have been thinking about this a lot, and Astera recently posted an essay contest asking for ideas that don’t fit the current infrastructure. (That’s why I’m finally writing this up, not because I think I’ll win the essay contest, but mostly because i’s an opportunity for people to consider whether/not this type of solution is a good idea as a separate analysis from “well, who is going to fund THAT?”. Let’s discuss and evaluate the idea, or riff on it, without being bogged down by the ‘how exactly it gets funded and managed over time’.)

I think we should create some kind of digitally-managed platform/ecosystem to do the following:

Incentivize and facilitate written (AI-assisted allowed) output of everything. Case reports and scenarios of people and what they’re facing. All the background information that might have contributed. All the data we have access to that is related to the case, plus other passive, easy-to-collect data (that may already be collected, e.g., wearables and phone accelerometer data) even if it does not appear to be related. Patient-perspective narratives, clinical interpretations, clinical data, wearable data – all of this.
A.) And, be willing to take variable types of data even from the same study population. For example, as a person with type 1 diabetes, I have 10+ years of CGM data. For a future study on exocrine pancreatic insufficiency, for example, not everyone will have CGM data, but because CGM data is increasingly common in people with T2D (a much larger population) and in the general population, a fraction of people will have CGM data and a fraction of people are willing to share it. We should enable this, even if it’s not for a primary endpoint analysis on the EPI study and even if only a fraction of people choose to share it – it might still be useful for subgroup analysis, determining power for a future study where it is part of the protocol, and identifying new research directions!
Host storage somewhere. There can be some automated checking against identifiable information and sanity checking what’s submitted into the repository, plus consent (either self-consent or signed consent forms for this purpose.)
Provide ‘rewards’ as incentives for inputting cases and data.
A) Rewards might differ for patients self-submitting data and researchers and clinicians inputting data and cases. Maybe it’s one type of reward for patients and a batch reward of a free consult or service of some kind for researchers/clinicians (e.g. every 3 case reports submitted = 1 credit, credits can be used toward a new AI tool or token budget for LLMs or human expertise consult around study design, or all kinds of things.)

B) Host data challenges where different types of funders incentivize different disease groups or families of conditions to be added, to round out what data is available in different areas.
Enable AI and human access (including to citizen scientists/independent researchers who don’t have institutions) to these datasets, after self-credentialing and providing a documented use case for why the data is being accessed.
A) Require anyone accessing the dataset to make their analysis code open source, or otherwise openly available for others to use, and to make the results available as well.

B) Tag anytime an individual dataset is used by a project, that way individuals with self-donated data (or clinicians submitting a case) can revisit and see if there are any research insights or data analysis that applies to their case.

C) Provide starter projects to show how the data can be used for novel insight generation. For example, develop sandboxes for different types of datasets with existing ‘lab notebooks’, so to speak, to onboard people to different datasets/groups of data, different types of analyses they might do, and to cut down on the environment setup barriers to getting started to analyzing this data.

D) Facilitate outreach to institutions, disease-area patient nonprofits and advocacy groups both to solicit data inputs AND to use the data for generating outputs.

Why should we do this?

Clinical trials do not gather all of the possible useful data, because it’s not for their primary/secondary endpoints. Plus, they would have to clean it upon collection. Plus storage cost. Plus management decisions. Etc. There’s a lot of real barriers there, but the result is that clinical trials do not capture enough or the most possible relevant data. So we need a different path.
Clinicians/clinical pathways don’t have ways to review data, so they avoid doing it. There’s no path to “submit this data to my record but I don’t expect you to look at it” in medical charts (but there should be). So we need a different path.
Disease groups/organizations sometimes host and capture datasets, but like clinical trials, this is limited data; it often comes through clinical pathways (further limiting participation and diversity of the data); it doesn’t include all the additional data that might be useful. So we need a different path.
Some patients do publish or co-author in traditional journals, but it’s a limited, self-selected group. Then there are the usual journal hurdles that filter this down further. Not everyone knows about pre-prints. And, not everyone knows how useful their data can be – either as an n=1 alone or as an n=1*many for it to be worth sharing. A lot of people’s data may be in video/social media formats inaccessible to LLMs (right now) or locked in private Facebook groups or other proprietary platforms. So we need a different path.

Thus, the answer to ‘why we should do this’ is recognizing that: AI does not create magic out of nowhere. It relies on training data and extrapolating from that, plus web search. If it’s not searchable or findable, and it’s not in the training data, it’s not there. Yes, even the newer models and prompting it to extrapolate doesn’t solve all of these problems. What AI can do is shaped disproportionately by formal literature, institutional documents, and whatever scraps of publicly available content remain. If we want to shape what’s possible in the future, we need to start now by shaping and collecting the inputs to make it happen. We can’t fix the past trial designs but we can start to fill in the gaps in the data!

Here is an example of how this might work and why it matters to build and incentivize this type of data sharing.

If we build and incentivize data sharing, the following individuals might self-donate their data and write-ups, or a clinician might submit them. Later, someone might analyze the data and put the pieces together.

Someone with type 1 diabetes (an autoimmune condition) and this new-onset muscle-related issue. Glucose levels are well-managed, and they don’t have neuropathy/sensory issues (which are common complications of decades of living with type 1 diabetes), and muscle damage and inflammation markers are normal. MRIs are normal. The person submits their data which includes their lab tests, clinical chart notes (scrubbed for anonymity), a patient write-up of what their symptoms are like, and exported data from their phone with years of motion/activity data.
A different person with Sjogren’s disease (also an autoimmune condition) and a similar new-onset muscle-related issue. There are known neurological manifestations or associations with Sjogren’s, but more typically those are small-fiber neuropathy or similar. The symptoms here are not sensory or neuropathy. MRIs don’t show inflammation or muscle atrophy. Their clinician is stumped, but knows they don’t see a lot of patients with Sjogren’s and wonders if there is a cohort of people with Sjogren’s facing this. The clinician asks the patient and gains consent; scrubs the chart note of identifying details, and submits the chart notes, labs, and a clinician summary describing the situation.
Later, a researcher (either a traditional institutional-affiliated researcher OR a citizen scientist, such as a third person with a new-onset muscle-related issue) decides to investigate a new-onset muscle-related issue. They register their hypothesis: that there may be a novel autoimmune condition that results in this unique muscle-related issue as a neuromuscular disease (that’s not myasthenia gravis or another common NMJ disease) that shows up in people with polyautoimmunity (multiple autoimmune conditions), but we don’t know which antibodies are likely correlated with it. The research question is to find people in the platform with similar muscle-related conditions and explore the available lab data to help find what might be the connecting situation and classify this disease or better understand the mechanism.

They are granted access to the platform, start analyzing, and come across an interesting correlation with antibody X, which is considered a standard autoimmune marker but one that doesn’t differentiate by disease, and which does highly correlate with this possibly novel muscle condition when it exists and is elevated in people with at least one existing autoimmune condition and these muscle-symptoms that are seronegative for every other autoimmune and neurologic condition. Further, by reading the clinical summary related to patient B and the self-written narrative from patient A, it becomes clear that this is likely neuromuscular – stemming from transmission failure along the nerves – and that the muscles are the ‘symptom’ but not the root cause of disease. This provides an avenue for a future research protocol to 1) allow these types of patients to be characterized into a cohort so this can be determined whether it is a novel disease or a subgroup of an adjacent condition (e.g., a seronegative subgroup); 2) track whether the antibody levels are treatment-sensitive or not or stay elevated always; and 3) cohorts of treatments that can be trialed off-label because they work in similar NMJ diseases even though the mechanism isn’t identical.
The mechanism for this novel disease isn’t proven, yet, but in the face of all the previous negative lab data and neurological testing patient A and patient B have experienced, it narrows it down from “muscle or neuromuscular” which is a significant improvement from their previous situations. Plus, this provides pathways for additional characterization; research; and eventual treatment options to explore versus the current dead ends both patients (and their clinical teams) are stuck in. And because there are no good clinical pathways for these types of undiagnosed cases, this type of insight development across multiple cases would not have occurred at all without this database of existing data.

2. The above is a small-n example, but consider a large dataset where there are hundreds or thousands of people with CGM data submitted. Plus meal tracking data, because people can export and provide that from whatever meal-logging apps some of them happen to use.

By analyzing this big dataset, an individual researcher could hypothesize that they could build a predictor to identity the onset of exocrine pancreatic insufficiency, which can occur in up to 10% of the general population (more frequently in older adults, people with any type of diabetes, as well as other pancreas-related conditions like pancreatitis, different types of cancer, etc), by comparing increases in glucose variability that correlate with a change in dietary consumption patterns, notably around decreasing meal size and eventually lowering the quantity of fat/protein consumed. (These are natural shifts people make when they notice they don’t feel good because their body is not effectively digesting what they are eating). They analyze and exclude the effect of GLP1-RA’s and other medications in this class: the effect size persists outside of medication usage patterns. This can later be validated and tested in a prospective clinical trial, but this dataset can be used to identify what level of correlation between meal consumption change and glucose variability change happen over what period of time in order to power a high-quality subsequent clinical trial. This may lead to an eventual non-invasive method to diagnose exocrine pancreatic insufficiency through wearable and meal-tracking data. (None exists today: only a messy stool test that no one wants to do and is hampered by other issues for accuracy.)

–

These are two examples and show how even small-n data or a large dataset where there are additional subgroups with additional datasets can be useful. In the past, it’s been a “we need X, Y, Z data from everyone. A, B, C would be nice to have, but it’s hard and not everyone will share it (or is willing to collect it due to burden), so we won’t enable it to be shared for the 30% of people who are willing”. Thus, we lose the gift and contributions from the people who are able and willing to share that data. Sometimes that 30% is a small n but that small n is >0 and may be the ONLY data that will eventually answer an important future research question.

We are missing so much, because we don’t collect it. So, we should collect it. We need a platform to do this outside of any single disease group patient registry; we need to support clinician and patient entries into this platform; we need to support intake of a variety of types of data; and we need to have low (but sensible) barriers to access so individuals (citizen scientists, patients themselves) can leverage this data alongside traditional researchers. We need all hands on deck, and we need more data collected.

Want signal? We need more noise (looking at the quiet bottleneck)

April 21, 2026April 21, 2026 by Dana Lewis

We need more signal, which means we want more noise. A lot of current scientific infrastructure is designed to minimize messiness: define a narrow question, collect the minimum data required to answer it, standardize the dataset, exclude complicating variables, finish the analysis, publish the result. That approach is understandable. It is also one reason we repeatedly fail the patients who most need evidence: people with unusual responses, multiple conditions, atypical phenotypes, rare diseases, or combinations of features that do not fit cleanly into existing bins. Our systems today are structurally designed to discard or never capture the kinds of heterogeneous, partial, contextual, or longitudinal data that could eventually make critical insights available to us.

My hypothesis is that one important scientific bottleneck is not a lack of intelligence, or even a lack of data in the abstract, but a lack of infrastructure for accepting, preserving, and reusing the kinds of data that fall outside formal trial endpoints and standard clinical workflows. I am proposing a solution: a shared platform that accepts optional, heterogeneous, participant- and clinician-contributed data, which will generate clinically useful subgroup hypotheses that standard trial and registry structures fail to generate.

Here are the quiet bottlenecks in the current system that I run into and that this platform would address:

Atypical, comorbid, and small-population patients are systematically left without usable evidence because current research systems are optimized to suppress heterogeneous data rather than preserve it. (Clinical trials are usually designed around narrow endpoint collection, fixed inclusion and exclusion criteria, and standardized datasets that are tractable for a specific immediate question. Patients are often told there is “no evidence,” when what is really missing is a system that could have captured and preserved evidence that can help with future translation for atypical or edge-case presentations.)
Useful data is routinely discarded because no existing structure is responsible for capturing it. (Clinical trials generally do not want to collect data outside primary and secondary endpoints because of cleaning, storage, analysis, and governance costs. Clinical care systems do not want to ingest large volumes of patient-generated data that clinicians are not expected to review. Disease registries are usually narrow and disease-specific. Journals are poor infrastructure for surfacing up data. There is no home for this data.)
AI and humans are constrained by the same missingness problem: the knowledge base is biased and uneven because we do not capture enough of the right kinds of real-world data. (LLMs and other AI systems are often criticized for bias, holes, and nonrepresentative training data. But this overlooks that clinicians and researchers are also reasoning from the same incomplete literature, selective trial populations, under-collected real-world evidence, and publication-filtered case reports. The bottleneck is upstream of both.)AI now makes it possible to overcome these constraints, but only if the data is collected and made available in the first place.

Current systems privilege uniform completeness over partial but valuable contribution, which causes preventable signal loss. (If not everyone has or is willing to provide the data, it’s not collected. Subsets of participants who are willing and able to contribute additional data, such as wearables, CGM, meal logs, phone sensor streams, or symptom data, are prevented from doing so.)

Why current structures produce these bottlenecks

No single existing institution is responsible for optional data intake, long-term stewardship, and broad downstream access. And different structures prioritize different data capture, with no harmonization between these two settings. Clinical trials are funded, regulated, and staffed to answer bounded questions. Clinical trial incentives reward endpoint completion, analyzable datasets, and publication-ready results. Anything beyond the core clinical trial protocol creates additional costs: more data cleaning, more storage, more governance, and more analytic work that may not directly serve the trial’s primary purpose. Under those conditions, narrowness is rational but it is also systematically lossy. Clinical care systems have a different but related design problem. Electronic health records are built for documentation, care coordination, and billing, not for capturing or allowing participant-generated, future-use data that a clinician does not need for real-time decision making. This illustrates the infrastructure gap: patients may have useful longitudinal data, but there is often no legitimate pathway to store it in a way that supports future analysis. Disease registries and advocacy-group datasets help in some cases, but they are typically narrow in scope, tied to a disease silo, and constrained by the same pressures toward standardization and limited datastreams. Publications are also poorly matched to this problem, because they are optimized for polished outputs, not for preserving heterogeneous data. Much of the infrastructure was shaped from prior underlying constraints (when data capture, storage, and analysis was more expensive).

Testable hypotheses that would address these challenges:

Allowing partial, nonuniform data donation from participants will outperform “uniform minimum dataset only” models for early discovery in rare, atypical, and comorbid populations.
Structured case narratives combined with quantitative data will enable more useful discovery than quantitative data alone for poorly characterized conditions, because the narrative context helps identify mechanistic or phenotypic patterns that are otherwise lost.
Modern tools (LLMs etc) make it feasible to analyze and normalize real-world participant-contributed data at a scale and cost that was previously impractical.
For some under-characterized conditions, a heterogeneous real-world repository can identify candidate biomarkers, phenotypic subgroups, or prospective-study designs and lead to a shorter timeline for protocol development and funding of eventual trials, compared to the status quo.

Here are a few example experiments we can use to validate these hypotheses:

Use heterogenous real-world data to test whether a shared repository can generate an earlier detection hypothesis that existing structures are poorly positioned to generate. For example, exocrine pancreatic insufficiency. EPI is common but underdiagnosed and its current diagnostic pathway is unpleasant (a stool test) and imperfect. As digestion becomes less effective, people often change what and how they eat before anyone labels it as a problem: meal sizes may shrink, fat and protein consumption may drift downward, symptom patterns develop, and glucose variability may shift in parallel, especially in people with diabetes or others who happen to have CGM data. A conventional clinical trial would rarely collect all of these data together (GI symptoms, meal logs, and CGM data). We have shown that a patient-developed symptom survey can effectively distinguish between EPI and non-EPI gastrointestinal symptom patterns in the general population. But this relies on people to know they have a problem and fill out the symptom survey to assess their symptoms. By analyzing CGM and meal logging data, we may be able to create a diagnostic signal from CGM data that may provide an earlier detection of EPI or other digestive problems, noninvasively and much earlier. If successful, the output would be a concrete, testable hypothesis for a future prospective study: for example, that a specific combination of changing meal patterns and glucose variability could serve as an early noninvasive screening signal for EPI.
A second, smaller experiment would test the same infrastructure in a very different setting: under-characterized autoimmune or neuromuscular overlap syndromes. Here the problem is not underdiagnosis at scale, but invisibility in small-n edge cases. Patients with unusual muscle-related symptoms, normal or ambiguous standard workups, and backgrounds that include autoimmune disease often remain isolated within separate clinics and disease silos. One person may carry a type 1 diabetes diagnosis, another Sjögren’s, another a different autoimmune history, and yet their new symptoms may share an overlooked mechanism. In current systems, these cases rarely become legible as a group because the relevant data are scattered across chart notes, patient stories, normal imaging, lab panels, and passive longitudinal data that no one is collecting or comparing systematically. This tests the same core hypothesis under tougher conditions: smaller numbers, less uniform data, less obvious endpoints, and a heavier dependence on narrative context. If the EPI case shows that optional heterogeneous data can support tractable hypothesis generation in an underdiagnosed condition, the neuromuscular case shows why the same infrastructure could matter even more in sparse-data, high-ambiguity situations where it is even harder to capture data to generate evidence in support of and funding for subsequent trials.

What we might learn if these fail

We will learn what the barrier is, whether it is still a problem of infrastructure; a lack of the right people (or AI) leveraging the data; whether partial nonuniform data donation is operationally feasible; and whether limiting factors are data availability, harmonization, governance, or analytic quality. Plus, we can determine whether certain diseases or use cases (e.g. developing novel diagnostics versus assessing medication responses) are better suited than others for this type of platform.

Why now?

Passive and participant-generated data collection is easier. Wearables, phone sensing, CGM data, meal logging apps, symptom trackers, and similar are now significantly more common. Technology makes it easier than ever to create custom apps to track n=1 data or study-specific data. Storage is cheaper. Technology improvements, most notably AI tools, have made it more tractable to collect data; and have made it more tractable for researchers to analyze this data. The remaining bottleneck is capturing, storing, and making the data available. It is less of a technological bottleneck and instead a bottleneck of funding/governance/etc. This is addressable now that the capture/analysis barriers have been lowered!

–

I don’t think the question we should be asking is whether every piece of heterogenous data will be useful, but whether we can afford to keep doing what we are doing (throwing away data and still expecting discovery for the populations our current systems and infrastructure already quietly fail).

–

Note: I am submitting this post to the Astera essay contest, which you can read about here. You should write up your ideas about the bottlenecks you see and submit as well! I also wrote an additional piece with more details and examples, which you can read here.

The data we are leaving behind in clinical trials, what it costs us, and why we should talk about it

April 16, 2026 by Dana Lewis

I talk a lot about the data we leave behind. A lot of this time, this is in the context of clinical trial design. But more recently, it’s also about the data loss that drives bias in AI. And actually…that same bias exists in humans. And seeking to fix one may also fix the other!

To clarify, it’s not that no one cares (as a reason for why data loss or missingness happens). It is an artifact of our systems, funding priorities, and a whole bunch of historical decision making. Clinical trials cost money and are usually designed to answer a question around safety or efficacy, often in pursuit of regulatory approval and eventual commercial distribution. We need that (I’m not saying we don’t!), but we also need funding sources to answer additional questions related to titration, individual variance, medication impacts, more diseases, etc.

A lot of trials exclude people with type 1 diabetes, for example, so it’s always a question when new medications or treatments roll out whether they are appropriate or useful for people with T1D or if there’s a reason why they wouldn’t work. This is because sometimes T1D might be seen as a muddy variable in the study, but a lot of times it’s just a copy-paste decision from a previous study where it did matter that is propagated forward into the next study where it doesn’t matter. There is no resulting distinction between the two: there is simply a lack of representation of people with T1D in the study population and this means it’s hard to interpret and make decisions about this data in the future.

A lot of decisions around what data is collected, or who is enrolled in a population for a study, is an artifact of this copy-paste! Sometimes literal copy-paste, and sometimes a mental copy-paste for “we do things this way” because previously there was a reason to do so. Often that’s cost (financial or time or hardship or lack of expertise). But, in the era of increasing technological capabilities and lower cost (everything from the cost of tokens to LLM to the decreasing cost of storage for data long-term, plus the reduced cost on data collection from passive wearables and phone sensors or reduced hardship for participants to contribute data or reduced hardship for researchers to clean and study the data) this means that we should be revisiting A LOT of these decisions about ‘the way things are done’ because the WHY those things were done that way has likely changed.

The TLDR is that I want – and think we all need – more data collected in clinical trials. And, I don’t think we need to be as narrow-minded any more about having a single data protocol that all participants consent to. Hold up: before you get the torches and pitchforks out, I’m not saying not to have consent. I am saying we could have MULTIPLE consents. One consent for the study protocol. And a second consent where participants can evaluate and decide what additional permissions they want to provide around data re-use from the study, once the study is completed. (And possibly opt-in to additional data collection that they may want to passively provide in parallel).

The reason I think we should shift in this direction is because that, out of extreme respect to patient preferences around privacy and protecting patients (and participants in studies – I’ll use participants/patients interchangeably because it happens in clinical care as well as research), researchers sometimes err on the side of saying “data not available” after studies because they did not design the protocol to store the data and distribute it in the future. A lot of times this is because they believe patients did not consent (because researchers did not ask!) for data re-use. Other times it’s honestly – and I say this as a researcher who has collaborated with a bunch of people at a bunch of institutions globally – inadvertent laziness / copy-and-paste phenomenon where it’s hard to do the very first time so people don’t do it, and then it keeps getting passed on to the next project the same way, because admittedly figuring it out and doing it the first time takes work. (And, researchers may have not included in their budgets to cover data storage, etc.). Thus this propagates forward. Whereas you see researchers who do this on one project tend to continue doing it, because they’ve figured it out – and written it into their research budgets to do so for subsequent projects. And other times, the lack of data re-use is a protective instinct because researchers may have concern that the data may be used in a way that is harmful or negative. Depending on the type of data (genetic data versus glucose data, as two examples), that may be a very legitimate concern of study participants. Other times, it may be at odds with the wishes of the broad community perspective. And sometimes, individuals have different preferences!

We could – and should – be able to satisfy BOTH preferences, by having an explicit consent (either opt-in or opt-out, depending on the project) that is an ADDITIONAL consent specifically indicating preferences around data being re-used for additional studies.

To emphasize why this matters, I’ll circle back to AI/LLMs. A criticism of AI is that they are trained on data that is not representative; has holes; or is biased. This is legitimate and an artifact of the past design of trials. I have been thinking through the opportunities this provides now, in the current era of trial design, to be proactive and strategic about generating and collecting data that will fill these holes for the future! We can’t fix the way past trials were done; but we can adjust how we do trials moving forward, fill the holes, and update the knowledge base. This actually then fixes the HUMAN PROBLEM as well as the AI problem: because these criticisms of AI are the same criticism we should be making about humans (researchers and clinicians etc), who are also trained on the same missing, messy, possibly biased data!

More data; more opt-in/out; more strategery in thinking about plugging the holes in the knowledge base moving forward in part by not making the same mistakes in future research that we’ve made in the past. We should be designing trials not only for narrow endpoints (which we can also do) for safety and efficacy and regulatory approval and commercial availability, but also for answering the questions patients need answered when evaluating these treatments in the future: everything from titration to co-conditions to co-medications to the arbitrary research protocol decisions around the timing of treatment or the timing of the course of treatment. A lot of this could be better answered by data re-use beyond the additional trial as well as additional data collection in conjunction to the primary and secondary endpoints.

All of this is to say…you may not agree with me. I support that! I’d love to know (constructively; as I said, no pitchforks!) what you disagree about, or what you are violently nodding your head in agreement about, or what nuances or big picture things are being overlooked. And, I have an invitation for you: CTTI – the Clinical Trials Transformation Institute – is hosting a 2-hour summit on April 28 (2026) for patients, caregivers, and patient advocates designed to facilitate discussion around the range of perspectives on these topics as they apply to clinical trials. Specifically 1) the use of AI in clinical trials and 2) perspectives on data re-use beyond the initial trial that data is collected for.

If you have strong opinions, this is a great place for you to share them and hear from others who may have varying or similar perspectives. I am expecting to learn a lot! This event is not designed around creating consensus, because we know there are varying perspectives on these topics, and thus especially if you disagree or have a nuanced take your voice is needed! (I may be in the minority, for example, with my thoughts above.) Participation is focused (because these topics are scoped to focus on clinical trials) on anyone who has ever been part of a clinical trial, is currently navigating one, made the decision to leave a trial early, or even those who looked into participating but ultimately decided it wasn’t the right fit .

You can register for the summit here (April 28, 2026 10am-noon PT / 1-3pm ET), and if you can’t attend, feel free to drop a comment here with your thoughts and I’ll make sure it is shared and included in the notes for the event that will also be shared out afterward aggregating the perspectives we hear from.

Which LLMs and how I am using them as of February 2026 plus a remote LLM prompting tool

February 17, 2026 by Dana Lewis

I thought I would share some of how I am using AI. Previously I’ve talked a lot about broad concepts of prompting LLMs and the types of projects that can be done. I’ve provided particular examples that I’ve found useful for n=1 custom software (to address software-shaped feelings, often) or for improving n=1*many software like my apps PERT Pilot (iOS | Android), Carb Pilot, etc. But I haven’t talked a ton about which LLMs I use and why.

There’s a reason for that.

I noticed back in the day (of artisanal hand coding, going uphill in the snow both ways to build things) that a lot of programmers would be super dismissive and bullying about which language/program you talked about using. Let’s say you picked up a project and built it in C++: someone might come in and declare that it is the stupidest thing ever, and you should’ve used Python. But if it works in C++…who cares? The same thing about whether you use a visual “IDE” or code from the terminal, and whether you use tabs or spaces, or prefer vi or vim or nano…who cares? Use what works for you. I always noticed and hated and tried to ignore the “you should do it this way!” unless there was a “hey, heads up, doing it this way is better because very concrete reason X,Y,Z”.

So when you read my blog posts about LLMs, you might pick up on my generic use of talking about AI/LLMs without calling out a specific one (for example, see my last post where I talked about using LLMs to build solutions for software-shaped feelings). That’s because if the first one you picked up was Claude, and you liked it – great. Use that. All of my advice regarding prompting and other stuff applied. But if you used and liked ChatGPT? Also great, advice also applies. It’s easy to read (as a non-technical person) advice that’s for ChatGPT and be confused about whether you can extrapolate it to another tool and environment. That’s now exacerbated by the fact that we went from web-based AI (think ChatGPT and Claude websites) to desktop and phone-based apps to now also agentic “CLI” (command line interface) options. There’s oodles of ways to use an LLM of choice depending on where you are, what you like, and what you are trying to do. Try one and if it works for you, great. Be willing to try other things, too, but it’s fine if it doesn’t work as well for you and you keep using what does work. (If it doesn’t work, that is a good reason to try something else, as different models are better at different things and the different tools may have different capabilities).

Here’s what I have used over time, what I’ve tried and why I’ve switched over – or not switched at all.

First, I mainly used ChatGPT (web) because that’s what was available in the early days. I found it useful especially as the models progressed. I also had tried Claude when it became available (web), but didn’t find it as useful. I tried a few times with different types of projects and prompts. It was ok-ish, but I preferred ChatGPT especially for technical projects. I also tried Gemini (web) and had a similar lackluster response. I was thrilled when there became a (Mac) app for ChatGPT, and when there became more functionality like tool integration. Before, I was having to copy in code and get it to re-write or advise, then I would copy/paste code back over. (Hey, still easier than noodling over stack overflow entries and trying to figure out how it applied to my project). But, it was burdensome. Then it got to where it could see the context of my file, but only one file. That was better but still lacked the context of everything else. However, for one-off questions about random topics and other types of non-coding work, I still preferred ChatGPT’s models overall, especially increasingly the models with thinking. I now use 5.2-thinking as the default for all my work (this was written in early February 2026; assume that in future when you read this, I will probably be on the latest thinking/reasoning models).

Note: if someone says “I used GPT 5.2” when describing what they did, you have to ask what level of thinking they had it set to. Was it auto mode? Or thinking mode? Yes, sometimes auto mode will eventually trigger thinking mode but it drastically differs based on the prompt, and I find most users on free accounts using auto don’t see it go into full thinking the way my prompts get 5.2-thinking from the start, and that influences how useful the answer is. And again, it likely doesn’t have context for the project or if it does only one file’s worth.

Meanwhile, Scott has been a big fan of Claude Code, the agentic CLI for Claude’s models. He’s very, very productive with it for work on his laptop using the CLI tools. I had on my list to try CLI tools, but I put it off for a long while in part because I had finally experimented with Cursor.

I started using Cursor to test if it was better (for me) for coding-related projects. It’s basically a desktop app that I can open a project folder in and see all the files – whether they’re XCode (iOS app) files or Android Studio kotlin or javascript or python or markdown or whatever. I don’t have to open all the different ‘run’ apps to work on the code (although I still need to use XCode or Android Studio to ‘build’ and run the simulator or deploy to my physical phones for testing, these are no longer my primary interfaces for the coding work). And, this means all the files in the project are *in context* (or, able to be searched within a prompt to give it context), without me having to go tell it to look at file A for context – it can look itself and figure out which file is relevant or has the relevant code. (This is also because of the increasing capabilities of ‘agents’ which can do more sophisticated multi-step things in response to your prompts.) Cursor allows you to pick which models you want to use, so you could limit it to just Claude or ChatGPT-related models, but I don’t – I use all the latest models. I can’t really tell a difference with this setup what model is being used (!) which honestly shocked me because from the web version I *can* tell such a difference between the two, but the Cursor-style setup that has context for the full project takes away that difference. And Cursor has been very fast to iterate and instead of having it be slow to go prompt by prompt, they now have planning mode and agents where you can start by having it plan a set of work and build a checklist (even a big one with lots of tasks) and then it’ll go do some, most, or occasionally all of it. It’s also gotten better about running things in a sandbox to test its work, so I spend a lot less time on iOS projects: for example, going into XCode and having to come back to Cursor and complain about a build error that is preventing me from testing. Instead of that happening 3 of every 4 times, it now seems like it happens only 1 of 4 times and often this is a very minor issue that it fixes with a single follow up action and I can build. So that prompt>build>test timeline loop has gotten WAY faster, even just comparing the last 3 months or so. Because I have found such success with my iOS projects, Cursor has become my go-to interface of choice harness/setup for most projects, including Android apps, iOS apps, new data science projects, and anything else that involves code and/or data analysis.

However, Cursor is a desktop app. One of the benefits of ChatGPT is that I could do something on the desktop app and walk away and go for a walk and if I thought of something, pull out my phone and add another prompt to it via the phone app in the same thread that had the same context window. (Mostly – it can’t access a code file from my phone, but whatever else was loaded in the chat history it has). This means that ChatGPT was still my mobile/phone LLM of choice. I often found myself with my phone dreaming up a new project and essentially doing “planning” mode with ChatGPT (5.2-thinking, as of Feb 2026) for scoping out a project and thinking through constraints. When I was back at my laptop, I would have ChatGPT write a summary and/or prompt to give to another LLM, then go give it to Cursor. I’d have Cursor riff on that plan and add to it, then go implement it. This has worked wildly well, but I do wish I had a way to do at least planning mode with Cursor from my phone.

But, aside from that, I have felt as productive with Cursor (for laptop usage) and ChatGPT (for phone based and non-coding usage) as Scott does with Claude Code (on his laptop; he also uses ChatGPT as his phone LLM of choice).

Lately, you might have heard about “OpenClaw” (aka “MoltBot” aka “ClawdBot” – it had a few name changes). It’s a security nightmare, so don’t just use it if you’re not thinking it through, but the TL;DR is that it’s a way to set up a way to send prompts to an LLM and have it run them on your computer, with full access to all the different tools and accounts you’ve set up. However, it’s a security nightmare and very risky, so most people shouldn’t be using it (including you, probably). The only reason I’m bringing it up is because I *wish* I had a way for mobile commands to a coding LLM that had access to my code, so I could basically instruct Cursor to work on something while I’m away from my laptop. But, I am not willing to set something up with permissions to remote control my laptop fully (which is basically what OpenClaw does), so I haven’t been able to do so.

Until this weekend.

I kept thinking that what I wanted was the ability to remotely prompt Cursor, because it has access to the full project. There are a few ways to do this, either via something like OpenClaw (nope, see above) or if you host your code on Github and run ‘cloud’ based LLMs on it. I didn’t want to do that, the projects I have are local on my computer, and I want the LLM to have context and ability to write code and edit code on that project. (Otherwise, I’ll just use ChatGPT which is sufficient on my phone for other things). This could be because I’m away from my laptop – cross country skiing in the mountains and thinking through projects and wanting to start a prompt on the drive home so it can have something for me to review and test when I’m back, or just in the other room and don’t want to go get my laptop out. If only there was a way to have Cursor check a Google Sheet, for example, for a new prompt and then go run it.

Light bulb.

Cursor (desktop) can’t, but a scheduled job on my computer could be set up to check a Google Sheet every so often and find the prompt and send it to an LLM agent that can be run on my laptop. I could have the LLM log the prompt and what it did and the output, so even though I wouldn’t see it in the ‘chat history’ of the desktop app the way I do with ChatGPT or Cursor (desktop), I could still review a summary of what it thought/did and review the code when I was back on my laptop. (Bonus: because this project folder is synced to a backup cloud that I have access to on my phone, I can review this from my phone, too!).

How did I figure this out and make it work? I used ChatGPT (as my phone-based brainstorm LLM app of choice) to talk through the idea and talk through technical options, including my ‘requirements’/preferences of not using Github/cloud based actions for this. This discussion laid out a plan and I was surprised that the Cursor CLI (as opposed to desktop) would work for this, which means I could download Cursor CLI and log in/set that up (under the same account I used Cursor Desktop with), and with a simple script I added to my Mac via Terminal, have it check the Google Sheet at the designated interval, find the prompt, run it, record the status in the sheet plus record a status in the log of the project.

So after all, I am finally using a CLI for an LLM! (Although, I will say after I downloaded it and installed and logged in just to set it up for this project, I actually hate the UI, go figure, so my resistance to CLI-based LLMs was probably an intuitive strong preference for GUI-based LLMs.) But I’m not using it directly as a CLI, my script on my Mac is calling it to do the work based on the prompt I put into a Google Sheet. Google Sheets, which I’m very comfortable with, becomes the place I prompt my code-based LLM to do remote work from. (FYI, for setup, I’m also using a free Google Cloud Console Project which you give permissions to which is part of the way it can read/write from the Google Sheet remotely.)

End to end, this setup involved 1) terminal (on my Mac); 2) Cursor CLI; 3) Google Cloud Console; 4) Google Sheets.

I will have to continue to set this up for other projects that I want to do, but the bulk of the hard work is done – the additional projects will be a few minutes of configuration and testing each time, so I’ll do that every time I touch those projects and find myself wanting to do remote work.

But this is exactly what I love about AI-driven development. You can build amazing things that would not have been in your wheelhouse to even attempt before. You can troubleshoot and fix all kinds of issues along the way on the big ambitious project that becomes a realistic option to build and implement, whether it’s just for you or it’s something that a lot of other people would use. And, you can use it to customize your environment and tools and make up completely new tools (again, which you never would’ve thought was possible to do before!) that enable you to do work in ways that weren’t possible before. I keep saying this, but it’s worth keeping a log somewhere of projects that are still “too hard” and coming back to them every few months and trying them again with newer models or setups. (If you haven’t used anything with ‘agents’, you REALLY should try this on a project.)

It’s exciting to keep adding to existing projects, building new projects you didn’t have time to do before, and building the projects that you only figured out how to dream up with the help of new technology.

Software-Shaped Feelings

February 9, 2026 by Dana Lewis

I have to ask myself these days, is this a software-shaped feeling?

This is a riff on something I see online more and more frequently, where people comment about recognizing if this is a “software-shaped problem”. Meaning, is this something that can be solved with software? More recently, this often means n=1 custom, boutique software that we can build ourselves. This is often easier and even faster than trying to search for something that maybe exists elsewhere and kinda works but not perfectly and requires a lot of work to tweak to the use case. Instead, now, we can spend the same (or often a lot less) time building something that perfectly fits.

I have been doing this for years. Juggling data in my head is hard – so I often turn to spreadsheets. For example, trying to figure out my enzyme dosing originally for exocrine pancreatic insufficiency – I had too many meals and too many variables to track, so I made a spreadsheet. When I then incorporated dosing enzymes for everything that I ate, that meant also everything I was eating while ultrarunning – which I did every 30 minutes to fuel. So I made a spreadsheet for that and then a template with dropdowns to use while running. I could quickly enter data that way, but Google sheets was slow to load on my phone and the extra seconds of delay was frustrating. Thus, I made a simple app I called “Macros On The Run” to allow me to more quickly open and tap the drop down and select my fuel item. Since I was building a custom app interface I could have all the summary data I wanted from my run, both hourly stats on calories and sodium consumed but also the entire per-run stats. I then was able to export my data to be able to analyze it later (particularly, also transposing it into the spreadsheet I use for food and enzyme intake). Does anyone else have this use case? No, probably not. But it was so empowering to be able to track and capture information in a format that worked well for me. And because I had learned how to build apps to build PERT Pilot to share with other people (because not everyone loves spreadsheet interfaces), I knew how to build apps, so I had the skillset that translated to figuring out how to build another app. This was before agentic AI, by the way, but this is now even easier.

Enter this week. I realized that I had expressed frustration to both my mom and Scott about a situation where I have a medicine/treatment that is done once a week, but it’s not a time-anchored or time-specific treatment. I don’t always take it Tuesday at 7pm. Depending on my schedule it could be 5pm, 9pm, whatever. But also, if I’m traveling, it can be a day earlier or later. It’s 7 days, plus or minus one day. Previously I was adding an event to the calendar for every week, and then moving it around. But I realized looking ahead at a busy summer full of travel that it was hard to move one without having to move another, because it’s not the week before that only matters, moving one also influences the chain of following events. If I usually do it on Tuesday but I’ll be traveling and not home until Thursday (and don’t want to do it while traveling), then I need to move the previous week from Tuesday to Wednesday so the following week’s Thursday is not out of the allowed ‘window’. So instead of 7-7-7, or ending up with 7-9-5 (which means two weeks are out of bounds), it becomes 7-8-6. But because these are single calendar events, there’s no alert when something goes out of bounds/out of the ‘allowed window’. Setting a recurring event (eg calendar event every 7 days) doesn’t resolve this, either. Juggling all of this in my head felt like a waste and non-optimal.

If only, I thought, I had a way to create an event type that was based on the “chain” relationship to the events before and after, that I could set to every 7 days but have an ‘allowed’ grace window of plus or minus a day, so that anything 6-8 days was allowed.

Google calendar doesn’t support this. But I know that you can subscribe to other calendars and show them, eg how I edit events in TripIt and subscribe to the calendar feed so I can see those events in Google calendar.

Thus, I found myself asking, “is this a software-shaped feeling?” of frustration? I can build apps, after all. Could I build an app that somehow publishes a calendar feed that I can see in Google calendar and see these events and get alerts when they are out of bounds? Ideally I’d be able to use Google calendar to edit these events, the way I do my other calendar events.

The mental model I had was app>feed>display in calendar. I was laying in bed, but I pulled open one of my LLMs that I have on my phone and sketched out the idea in a few sentences and asked what was possible to do and what technically it would take to do this. It brainstormed two key options, one with Google authentication and complicated multi-step back end (storage and databases and hosting and servers and all the stuff I *can* do but hate doing and doesn’t make sense for a quick n=1 prototype), and one simple one where the app would create its own iCloud calendar and then publish a feed I could see via the Google calendar. Aha, I thought, that’s it.

The next day I sat down at my laptop and used my coding LLM of choice. I asked it to build this app where it would allow me to create a ‘series’ of events with a set window (eg default to Tuesday at 7pm) and allow me to set a grace period (eg +/-1 day) and see the distance between events and flag a visual cue if they fall out of the window. It should then create events in an iCloud calendar. I would then subscribe and view it via Google calendar, so I could see it via my laptop or phone. Eventually I would see if I could edit it from those views, but for now, just being able to push and adjust from the app would be fine. (Note: my prompt was a little more specific than this, but the important part wasn’t telling it how to build the app or what I wanted it to look like. The important part is making sure it understands the end goal and user interactions so we design the backend and the front end to support what I actually want to do as the end user.)

It…did it. This isn’t a story of “one-shotting” and getting things perfectly from a single prompt, but I continue to be appreciative that the first hours of setting up a project and getting it to build on your device and get the basic functionality working that used to take 4-6 hours and lots of gnashing teeth is now a 15-20 minute endeavor, usually. And that’s what happened here, I had a working functional prototype working on my phone in about 15 minutes. I spent more time after that making it look better, testing it, adjusting events, etc, but the initial setup and functionality was a very quick process. That’s huge. For me, it doesn’t matter what the total amount of time it is to get a project ‘done’ or usable for real-life testing. You’ll see people talk about how you get 80% of the work done quicker but it ‘takes longer’ for the last 20%, but I honestly think I do way more (so it’s not just 20%) when I haven’t exhausted myself gnashing my teeth about the fundamental basic how-does-it-work and does-it-build and what-is-this-build-error.

This app probably doesn’t matter to anyone else, but if you have a use case for it and would like to try it, let me know. I called it SchedulerPilot. It creates a new iCloud calendar called SchedulerPilot that you can see on your phone, and then also subscribe to elsewhere to view (e.g. if you set it to be viewable via a link), such as in Google calendar. That means I can give Scott access to see it the way he sees my other calendars, plus view it from my browser-based calendar view on my laptop. I can’t edit events from Google calendar in the browser, but I was able to (much more easily than I expected) add functionality to edit directly from my phone’s calendar app the way I usually do on the go. I also then was able to add functionality in the app for it to flag when the in-app view and calendar view were out of sync. It shows a list of events and how they differ and I can choose whether I pull calendar changes into the app view, or if I did the tweaking in the app, push those changes back to the calendar. They automatically sync. I can also add notes to the event and ‘lock’ it so if I make other adjustments and push updates, it doesn’t overwrite it. This is key for travel-based constraints where I am definitively moving it to do when I get home from a trip, but sometimes I haven’t booked flights for the trip so looking at my calendar it may otherwise be confusing WHY the event is moved for the week. Having a lock shows it’s there for a reason, and the optional note also provides good context clue for why it’s moved. I can also add more events in the future with the tap of a button, if I’m still using this as my method for scheduling in the future (and I’m guessing I will be).

Here’s an animated demo showing the point of the app and why it’s useful:

software-shaped feelings. a blog post by Dana M. Lewis on DIYPS.org The point isn’t convincing you to want to use my app. Most people don’t have a use case for this. But I want more people to build the patterns of recognizing when their feelings are trying to tell them something (e.g. this is a problem we could work on improving, even if it is not solvable) and build the skills of identifying when this is a software-shaped feeling. Especially when we are dealing with health-related situations and especially chronic non-curable diseases, and especially ones with treatments or medications that are not fun, it is so important to solve friction and frustration whenever and wherever we can. Not everything is a software-shaped feeling, but the more we recognize and address, the better off we are. Or at least I am, and I hope to help others do the same.

PS – If you find yourself with a software-shaped feeling and aren’t sure where to start, feel free to reach out and I’m happy to help chat and brainstorm and help you figure out which LLM tools work for you to help build software that fit those feelings. (Even if you tried a particular LLM in the past, they are frequently updating models and tools and it is worth trying again. They have gotten way better and require way less specific prompting, like I outlined here – although there may be some tips you still find useful in this post.) It used to be that you had to fund someone or badger someone to help build something if you didn’t have previous technical skills (or invest a LOT of time and energy) to learn them to do a thing. Now, you don’t have to do that, or plan to have a company to get funding to build a prototype. You can just…build things. And it’s ok if it’s “just” a n=1 solution. If it works for you, it’s worth the time. And chances are, it’ll be something that works for someone else, too. And in the meantime, you’ll have made something that works for you. If you felt like you needed permission, you have it. It won’t fix everything, but that doesn’t mean you should fixing what you can. It feels really good to have forward progress and to do something productive.

Baseline Pilot – a leading indicator for biometric data and tool for reducing infection spread

January 22, 2026 by Dana Lewis

What if you could stop the spread of infection once it arrives at your house? This is easier to do now than ever before in the era of wearables like smart watches and smart rings that gather biometric data every day and help you learn what your baseline is, making it easier to spot when your data starts to deviate from baseline. This data often is the first indicator that you have an infection, even before you develop symptoms sometimes.

But, you need to know your baseline in order to be able to tell that your data is trending away from that. And despite the fact that these new devices making it easier to have the data, they actually make it surprisingly challenging to *quickly* get the new data on a daily basis, and the software they have programmed to catch trends usually only catches *lagging* trends of changes from baseline. That’s not fast enough (on either of those metrics) for me.

(The other situation that prompted this is companies changing who gets access to which form of data and beginning to paywall long-time customers out of previous data they had access to. Ahem, looking at you, Oura.)

Anyway, based on past experiences (Scott getting RSV at Thanksgiving 2024 followed by another virus at Christmas 2024) we have some rich data on how certain metrics like heart rate (RH), heart rate variability (HRV), and respiratory rate (RR) can together give a much earlier indication that an infection might be brewing, and take action as a result. (Through a lot of hard work detailed here, I did not get either of those two infections that Scott got.) But we realized from those experiences that the lagging indicators and the barriers in the way of easily seeing the data on a daily basis made this harder to do.

Part of the problem is Apple and their design of “Vitals” in Apple Health. They have a “Vitals” feature that shows you ‘vital’ health metrics in terms of what is typical for you, so you can see if you fall in the range of normal or on the higher or lower end. Cool, this is roughly useful for that purpose, even though their alerts feature usually lag the actual meaningful changes by several days (usually by the time you are fully obviously symptomatic). But you can’t reliably get the data to show up inside the Vitals section, even if the raw data is there in Apple Health that day! Refreshing or opening or closing doesn’t reliably force it into that view. Annoying, especially because the data is already there inside of Apple Health.

This friction is what finally prompted me to try to design something: if the data is there inside Apple Health and Apple won’t reliably show it, maybe I could create an app that could show this data, relative to baseline, and do so more reliably and quickly than the “Vitals” feature?

Turns out yes, yes you can, and I did this with BaselinePilot.

BaselinePilot is an iOS app that pulls in the HealthKit data automatically when you open it, and shows you that day’s data. If you have a wearable that pushes any of these variables (heart rate, heart rate variability, respiratory rate, temperature, blood oxygen) into Apple Health, then that data gets pulled into BaselinePilot. If you don’t have those variables, they don’t show up. For example, I have wearables that push everything but body temp into Apple Health. (I have it on a different device but I don’t allow that device to write to Health). Whereas Scott has all of those variables pushed to Health, so his pulls in and displays all 5 metrics compared to the 4 that I have.

What’s the point of BaselinePilot? Well, instead of having to open Apple Health and click and view every one of those individual metrics to see the raw data and compare it to previous data (and do it across every metric, since Vitals won’t reliably show it), now at a glance I can see all of these variables raw data *and* the standard deviation from my baseline. It has color coding for how big the difference is and settings to flag when there is a single metric that is very far off my baseline or multiple variables that are moderately off the baseline, to help me make sure I pay attention to those. It’s also easy to see the last few days or scroll and continue to see the last while, and I can also pull in historical data in batches and build as much history as I want (e.g. hundreds of days to years: whatever amount of data I have stored in Apple Health).

So for me alone, it’s valuable as a quick glance “fetch my data and make sure nothing is wonky that I need to pay attention to or tell someone about”. But the other valuable part is the partner sharing feature I built in.

With partner sharing, I can tap a button (it shows up as a reminder after your data is synced) and text a file over to Scott (or vice versa). Opening the file in iMessage shows a “open in BaselinePilot” button at the bottom, and it immediately opens the app and syncs the data. You can assign a display name to your person and thus see their data, too, in the same format as yours. You can hide or delete this person or re-show them at any time. This is useful for if you are going on a long vacation and sharing a house with family members, for example, and so you want to share/see your data when you’re going to be in physical proximity but then don’t need to see them after that – you can hide them from view until that use case pops up again.

Screenshots of BaselinePilot, showing 72 days of simulated data for the user (not actually my data) and the display with a simulated partner called "Joe". — Simulated data and simulated partner data displayed in BaselinePilot.

Ideally, I’d love to automate this data syncing with partners (who agree) over Bluetooth, so you don’t have to tap to share the file on a regular basis. But, that won’t work with the current design of phones and the ability to background sync automatically without opening the app, so I’ve stopped working on Bluetooth-based solutions given the technical/policy constraints in the phone ecosystems right now. Eventually, this could also work cross-platform where someone could generate the same style file off of their Android-based BaselinePilot and be able to share back and forth, but Scott and I both use iPhones so right now this is an iOS app. (Like BookPilot, I built this for myself/our use case and didn’t intend to distribute it; but if this sounds like something you’d use let me know and I could push BaselinePilot to the app store for other people to use.)

BaselinePilot: a leading indicator for biometric data and tool for reducing infection spread. A blog post by Dana M. Lewis on DIYPS.org All of this data is local to the app and not being shared via a server or anywhere else. It makes it quick and easy to see this data and easier to spot changes from your normal, for whatever normal is for you. It makes it easy to share with a designated person who you might be interacting with regularly in person or living with, to make it easier to facilitate interventions as needed with major deviations. In general, I am a big fan of being able to see my data and the deviations from baseline for all kinds of reasons. It helps me understand my recovery status from big endurance activities and see when I’ve returned to baseline from that, too. Plus the spotting of infections earlier and preventing spread, so fewer people get sick during infection season. There’s all kinds of reasons someone might use this, either to quickly see their own data (the Vitals access problem) or being able to share it with someone else, and I love how it’s becoming easier and easier to whip up custom software to solve these data access or display ‘problems’ rather than just stewing about how the standard design is blocking us from solving these issues!

What else have I built that you might like to check out? I just built “BookPilot”, a tool to help you filter book recommendations by authors you’ve already read, based on the list of books you’ve already read from your library data. If you use iOS, check out Carb Pilot to help get AI-generated estimates (or enter manual data, if you know it) to track carbs or protein etc and only see which macronutrients you want to see. If you have EPI (exocrine pancreatic insufficiency, also called PEI), check out “PERT Pilot” either on iOS or Android to help you track your pancreatic enzyme replacement therapy.

BookPilot: What Should I Read Next?

January 18, 2026February 18, 2026 by Dana Lewis

Book hangovers are the worst. By book hangover, I mean that feeling you get at the end of a book when you come up for air and don’t know what you’re going to read next. In general, or because you have to ‘world switch’ from one type of book or one genre or one era to another (my most common cause), or because you don’t have any books picked out to read next.

I get this feeling, a lot, because I read a lot (hundreds of books per year). I also listen to a lot of audiobooks when I’m out doing long distance activities that take several hours (e.g. ultrarunning, hiking, or cross country skiing). So while I read 5x more books than I listen to audiobooks, I still consume several audiobooks per month, too, but I’m picky about what I like to read versus what I like for audiobook content. I regularly and periodically peruse catalog additions to my various* libraries’ digital collections under genres I like to read and under audiobook categories, putting things on hold so I always have a pipeline of things ready to read or listen to. But, this relies on me periodically doing so, and sometimes the influx of new things to read based on those effort dries up and I have fewer books on hand than I would like, especially when I know I’m going to be reading more (e.g. I have some downtime from not feeling well and will be reading more than normal or when I’m traveling/on vacation).

It occurred to me the other day that it would be nice to be able to automatically check authors I have read for new books and to be able to put those books on hold. The problem is that I read a lot. I have dozens if not hundreds of authors I like, and while I remember a few to check, I don’t have a good way to do this systematically. My brain finally put 2 and 2 together this week when it occurred to me that if Libby (the e-book/reading app now used by most of my libraries) allowed me to export my data, I could systematically list and look up authors and check for recent/new additions to their catalog. Ooooh.

Like most things now, there are usually ways to export or access all sorts of data whenever you’re ready to use it. Libby actually now makes it easy in the app to do this, without having to request or log in to the web portal or do any obnoxious behaviors. Tap Shelf>Timeline>look at “Actions” button in the top right. It gives you not one but THREE ways to export your data, wahoo! If I have the data, what could I do with it?

(TL;DR the rest of this: in less than a day, I built a tool that I call BookPilot which allows me to take the Libby data, parse it for the books & authors I have read, check those authors for every book they’ve ever written, then display it for me. BookPilot solves the ‘what should I read next?’ problem by systematically finding all unread books from authors I have already read. I can then easily mark off books I’ve read elsewhere (e.g. read before my Libby history started or in physical format), kick out books I know I don’t want to read, and otherwise have an awesome list of books ready to go the next time I want to spend some time checking out books and/or putting more things on hold! It works really well and that’s just on the authors I’ve already read – I plan to also add recommendations for new authors that match my favorite authors, genres, etc. There is a web dashboard where you can view and interact with the recommendations as well as the ability to work with this data via the command line.)

The whole goal was to help fuel my book pipeline and to be able to recommend books that are highly probable that I want to read, based on my past reads, but to automatically filter by what I’ve already read. (That’s a problem with asking chatbots or using other tools: it’ll show you ‘books like this’ but when you read hundreds per year, you don’t remember the covers or names of all the books you’ve read so you spend a lot of time re-checking things you’ve in fact already read.)

I started by taking the Libby data export (you can get it as CSV, json, or html) and having Cursor write a script to pull the book title and author for everything I’ve read in my export. This is about 800 books and ~350 or so authors from the last 2.75 years (when I switched from Overdrive to Libby and it started recording my history; before I wasn’t having it log my reads). It then takes every single author on the list, queries the Open Library API to find the author’s Open Library ID, then fetches all their works (up to 100 books per author at a time) using the author’s works endpoint; it then supplements this data with Google Books API queries. All API responses are cached locally to avoid rate limits, and requests include built-in rate limiting delays between calls. It stores all books by each author with metadata: title, ISBN, publication date, series information, categories/genres, format availability. It then cross-references catalog books with my reading history to mark read/unread status, attempts to filter out duplicates and non-English versions (e.g. “Anne of Green Gables” and “Anne of Green Gables (German Edition)” versus Anne of Green Gables in the actual german language title and also “Anne of Green Gables / Anne of Avonlea (Box Set)” etc). It takes a while if you have hundreds of authors but the script is set up so you can start/stop it and it will pick up where you left off. The next time you check, it will check and only add books that are more recently published (customizable thresholds, of course) so future catalog checks will be quick to look for recent additions.

Then I have a dashboard that sorts and shows me all these books, ordered by series (when series info is available) so I can see a) series I have not read from authors I have already read and b) any books in a series that I have partially read; I can also sort by author’s name or highest count of the books I haven’t read, e.g. maybe I’ve read one book from an author but they have another 30 books to consider!

(On first pass, I still need to go through and mark books that I have read from >=3 years ago digitally and/or in physical form. But a quick look has already shown that this system works great and I’ve already been able to instantly add a bunch of books to my to-read list and holds already!)

I added a thumbs up feature which automatically ports a book to my “books to read” tab, which answers my “what should I read next?” question. If I thumbs down a book, it goes away from the dashboard. I can also tag “already read” (also disappears it), “not in English” (e.g. my filters missed that this is a non-English version on the first pass) or “duplicate” for duplicate titles that have somehow crept into the listing.

I have separate recommendation lists for authors I’ve listened to (audiobooks) versus authors I’ve read (ebooks), so I can also have a good queue to fill for similar audiobook content.

I have a ton (hundreds of audiobooks, thousands of ebooks) to review, based on my ~800 books read in the last <3 years, from 350+ distinct authors. It’s delightfully overwhelming to have this many recommendations! There is nothing worse than a book hangover combined with having nothing in the reading queue and having to fight the book hangover and having to simultaneously search for what’s available and what you want to read next. (It’s like feeling hangry…book hangover hangry?) This system now means I won’t have that combination problem again: I will always have books lined up to read and if not I can quickly and more easily identify off this list from my known authors where they’ve added books or they have additional series or I can (eventually) find series from the same “era”/”genre”/”world” to continue reading and pick up where my brain left off.

Book Pilot series recommendation of books you have not read from authors you have already read

Book Pilot dashboard recommendation of books you have not read from authors you have already read.

Eventually, I’m going to add some recommendations for new authors that ‘match’ my most-read authors in different categories. But I don’t have to, yet, because I have so many high-ROI options based on my current author list! And the next time I drop in an updated Libby export, it will add the new authors I’ve read *and* automatically remove books from my “books to read” list that appear in my reading history.

BookPilot: answering 'what should I read next' by filtering what I have already read. A blog post from Dana M. Lewis on DIYPS.org I haven’t open-sourced BookPilot yet, but I can (UPDATE: it’s now open source!)) – if this sounds like something you’d like to use, let me know and I can put it on Github for others to use. (You’d be able to download it and run it on the command line and/or in your browser like a website, and drop your export of Libby data into the folder for it to use). (And did I use AI to help build this? Yes. Could you one-shot a duplicate of this yourself? Maybe, or otherwise yes you could in several hours replicate this on your own. In fact, it would be a great project to try yourself – then you could design the interface YOU prefer and make it look exactly how you want and optimize for the features you care about!)

* Pro tip: if you live in Washington state, most county libraries have “reciprocal” agreements if their counties offer services to each other. This means that because I lived in Seattle and have a SPL card and a King County (KCLS) card, I can also get Pierce County, Sno-Isle, etc etc etc…. It’s mainly digital collection access, but this is amazing because you can have all of these library cards added to your Libby account and when you want to go get a book, you can check ALL of your catalogs. Sometimes a book is on most of these systems and I can get on the hold list for the one with the shortest wait time. Other times, it’s only in ONE catalog and I wouldn’t have been able to get it without these reciprocal county cards because it wasn’t in SPL or KCLS (my primary local libraries)! And even when books are not in any collection yet you can add a smart tag and be notified automatically whenever something IS added to *any* of your libraries. It’s amazing. Not sure if other states or areas have these types of setups but you should look to see if you can access other catalogs/get cards, and if you live in Washington and love to read, definitely do this!

What else have I built that you might like to check out? If you use iOS, check out Carb Pilot to help get AI-generated estimates (or enter manual data, if you know it) to track carbs or protein etc and only see which macronutrients you want to see. If you have EPI (exocrine pancreatic insufficiency, also called PEI), check out “PERT Pilot” either on iOS or Android to help you track your pancreatic enzyme replacement therapy.

What you shouldn’t take away from my talk about patient experiences of using AI in clinical healthcare

December 17, 2025December 31, 2025 by Dana Lewis

I was asked to contribute a talk in a session at Stanford’s recent AI+Health conference. I spoke alongside two clinician researchers, and we organized the session so that I would talk about some individual patient experiences & perspectives on AI use in health, then scale up to talk about health system use, then global perspectives on AI for health-related use cases.

One thing I’ve been speaking about lately (including when I was asked to present in DC at the FDA AI workshop) is about how AI…is not one thing. There are different technologies, different models, and they’re going to work differently based on the prompts (like our research showed here about chart notes + LLM responses, as evaluated by a patient and clinician) as well as whether it’s a one-off use, a recurring use, something that’s well-defined in the literature and training materials or whether it’s not well-defined. I find myself stumbling into the latter areas quite a bit, and have a knack of finding ways to deal with this stuff, so I’m probably more attuned to these spaces than most: everything from figuring out how we people with diabetes can automate our own insulin delivery (because it was not commercially available for years); to figuring out how to titrate my own pancreatic enzyme replacement therapy and building an app to help others track and figure things out themselves; to more recent experiences with titration and finding a mechanistic model for an undiagnosed disease. The grey area, the bleeding edge, no-(wo)man’s land where no one has answers or ideas of what to do next…I hang out there a lot.

Because of these experiences, I see a lot of human AND technology errors in these spaces. I see humans make mistakes in chart notes and also in verbal comments or directions to patients. I see missed diagnoses (or wrong diagnoses) because the medical literature is like a game of telephone and the awareness of what conditions are linked to other conditions is wrong. I see LLMs make mistakes. But I see so many human mistakes in healthcare. One example from my recent personal experiences – it’s 2025 and a clinical team member asked me if I had tried cinnamon to manage my glucose levels. This was after she had done my intake and confirmed that I had type 1 diabetes. I looked at her and said no, because that would kill me. She looked surprised, then abashed when I followed that comment that I have to take insulin because I have type 1 diabetes. So I am maybe less bothered than the average person by the idea that LLMs sometimes make mistakes, say a wrong (or not quite right, even if it’s not wrong) thing, or don’t access the latest evidence base. They can, when prompted – and so can the human clinical teams.

A big point I’ve been bringing up in these talks is that we need everyone to care about the status quo of human, manual healthcare that is already riddled with errors. We need everyone to care about net risk reduction of errors and problems, not focus on additive risk.

We saw this with automated insulin delivery – people without diabetes were prone to focus on the additive risk of the technology and compare it to the zero risk they face as a person without diabetes, rather than correctly looking at the net risk assessment of how automated insulin delivery lowers the risk of living with insulin-managed diabetes even though yes, there is some additive risk. But almost a decade later, AID is now the leading therapy choice for people with insulin-managed diabetes who want it, and OS-AID is right there in the standards of care in 2026 (and has been for years!!!) with a strong evidence base.

I also talked about my experiences observing the real use of clinical scribe tools. I talked more in detail about it in this blog post, but I summarized it in my talk at Stanford, and pointed out how I was surprised to learn later – inadvertently, rather than in the consent process – that the scribe tool had access to my full medical record. It was not just transcribing the conversation and generating chart notes from it.

I also pointed out that my health system has never asked me for feedback about the tool, and that I’ve actually seen my same clinician use multiple different scribe technologies, but with no different consent process and no disclosure about chart access or any differences in privacy policy, retention timeline, etc. (Don’t pick on my clinician: she’s great. This is a point about the broader systematic failures.)

This is where I realized later people might have taken away the wrong point. This was not about me being a whiny patient, “oh they didn’t ask for my feedback! My feedback is so important!” and self-centered.

It was about flagging that these technologies do not have embedded feedback loops from ALL stakeholders, and this is more critical as we roll out more of these technologies related to healthcare.

It’s one thing to do studies and talk about user perspectives and concerns about this technology (great, and the other two presenters did an awesome job talking about their work in these spaces).

But we need to do more. We need to have pathways built in so all stakeholders – all care team members; patients; caregivers/loved ones; etc. – have pathways to talk about what is working and what is not working, from everything from errors/hallucinations in the charts to the informed consent process and how it’s actually being implemented in practice.

It matters where these pathways are implemented. The reason I haven’t forced feedback into my health system is two-fold. Yes, I have agency and the ability to give feedback when asked. Because I’ve worked at a health system before, I’m aware there’s a clinic manager and people I could go find to talk to about this. But I have bigger problems I’m dealing with (and thus limited time). And I’m not bringing it up to my clinician because we have more important things to do with our time together AND because I’m cognizant of our relationship and the power dynamics.

What do I mean? The clinician in question is new-ish to me. I’ve only been seeing her for less than two years, and I’ve been carefully building a relationship with her. Both because I’m not quite a typical patient, and because I’m not dealing with a typical situation, I’m still seeking a lot from her and her support (she’s been great, yay) to manage things while we try to figure out what’s going on. And then ditto from additional specialists, who I’m also trying to build relationships with individually, and then think about how their perceptions of me interplay with how/when they work with each other to work on my case, etc.

(Should I have to think about all this? Do I think about it too much? Maybe. But I think there’s a non-zero chance a lot of my thinking about this and how I’m coming across in my messages and appointments have played a role in the micro-successes I’ve had in the face of a rubbish and progressive health situation that no human or LLM has answers for.)

So sure, I could force my feedback into the system, but I shouldn’t have to, and I definitely shouldn’t have to be doing the risk-reward calculation on feedback directly to my clinician about this. It’s not her fault/problem/role and I don’t expect it to be: thus, what I want people to take away from my talk and this post is that I’m expecting system-level fixes and approaches that do not put more stress or risk on the patient-provider relationship.

The other thing I brought up is a question I left with everyone, which I would love to spur more discussion on. In my individual case, I have an undiagnosed situation. A team of specialists (and yes, second opinions) have not been able to diagnose/name/characterize it. I have shifted to asking providers pointedly to step away from naming and thinking broadly: what is their mental model for the mechanism of what’s going on? That’s hard to answer, because providers aren’t often thinking that way. But in this situation, when everything has been ruled out but there is CLEARLY something going on, it’s the correct thing to do.

And for the last year, the LLMs had a hard time doing it, too. Because they’re trained on the literature and the human-driven approach to make differential diagnoses, the LLMs have struggled with this. I recently began asking very specifically to work on mechanistic models. I then used that mechanistic model to frame follow up questions and discussions, to rule things in/out, to figure out where there are slight overlaps, to see where that gives us clues or evidence for/against our mechanistic model hypothesis, and to see what treatment success / failure / everything in between tells us about what is going on. Sure, a name and a diagnosis would be nice, but it’s been so relieving to have at least a hypothetical mechanistic model to use and work from. And it took specific probing (and the latest thinking/reasoning models that are now commonly available). But why am I having to do it, and why are my clinicians not doing this?

Do clinicians have an obligation to disclose when they are not using AI? I know some of the answers to the question of why clinicians aren’t doing this. But, the question I asked the Stanford AI+Health audience was to consider why we focus so much on informed consent for taking action, but we ignore the risks and negative outcomes that occur when not taking action.

And specifically in rare/undiagnosed diseases or edge cases of known diseases…do clinical providers have an obligation now to disclose when they are NOT using AI technology to facilitate the care they are providing?

It’s an interesting question, and one I would love to keep discussing. If you have thoughts, please share them!

Chicken, foxes, rattlesnakes, and the Hypershell X Ultra

December 4, 2025December 4, 2025 by Dana Lewis

A chicken, a fox, and a rattlesnake (mountain) equals an adventure, and one I didn’t think I would get to do this year.

(If you are new to the idea of an ‘exoskeleton’ or you know me and haven’t read my prior post about it, read this post first for context on exoskeletons, my experience with it so far – and more details on why I have been using one for the last few months.)

In August, I bought a Hypershell X Pro exoskeleton, for many reasons. For me, and my individual situation, it has been a huge instrument of freedom, allowing me to get back to some semblance of ‘normal’ volumes and duration of activity (at least for hiking) than I was able to do earlier this year. I put ~250 miles on it within the first 3 months of using it.

Because I’ve been using it, I joined one of the Hypershell groups on Facebook and saw them post about a contest, where they were seeking 10 people who would create user-generated content (aka, take pictures and videos of themselves using it) of their next version, called the Hypershell Ultra. It was centered around doing a ‘challenge’ hike or experience. I applied, thinking I wouldn’t get selected, because 1) I have a condition which is why I’m using it; 2) and/or I already have the Pro so they’d maybe pick people who are all brand new to exoskeletons and 3) I post a lot of trail/adventure pictures but it’s more of nature, not myself, and I don’t have a ton of followers on public platforms – I’m not really an “influencer”. But you don’t get a ‘yes’ unless you apply and try, so I applied anyway. And somehow, I was selected! That means they sent me a Hypershell X Ultra, for free. If I meet all the terms and conditions of the challenge, I get to keep it, if not they’ll want it back. But I was given it to use for free, so factor that in below accordingly (although you might be surprised when you read to the very end of this post).

Why I wanted to do the challenge and try the Hypershell X Ultra

There are a few specific reasons why I really wanted to try the Ultra and was excited about getting access to one. For context, they came out this fall and were marketed at $1,999. That’s…a lot of money. I spent $1,199 on a Pro model which was a lot (but I’m definitely getting my money’s worth from it and am glad I got it). However, as someone who just bought a Pro, I was not interested in buying an Ultra at the $2,000 price point. But I definitely wanted to try it, because the Ultra has some differences from the Pro. Namely, 1) it supposedly has reengineered motors that are more efficient, so they claimed you would get more mileage out of each battery; 2) it has Apple watch support so you don’t have to pull your phone out and unlock it and open the app in order to do certain things while active.

Those, for my use case, would be a nice improvement. In most of my hikes, I have had Scott (my husband) carry the spare battery and we swap it out mid-hike so that I can use as much power as I need. With two batteries, I can do 8-10 mile round trip hikes (and even those with ~3000+ feet of elevation gain) without fully running down the second battery. For me, and the type of adventures I’m doing, one battery isn’t enough (it handles about 4-5 miles of moderate-high intensity flat and maybe 3-4 miles of uphill adventures). So more mileage out of the same two batteries sounded great. That’s also where the watch view comes into play. I found, with the Pro model, that I didn’t like leaving adaptive mode on and instead, having it on Walking mode worked better for me (it still adapts to downhill etc automatically). (More on why about the modes in my other post). But, there are times where I would want to change the mode or would need to check the battery because I’m prone to getting in the zone and charging uphill on my hike and running the battery all the way down to 0, where it dies without warning. There’s no audio or visual cue on the device if you’re actively moving to indicate that you’re about to run the battery down – you just get to the point where it suddenly stops providing assistance and you notice it. Then you stop and change the battery. Which is not a major big deal, but the Hypershell mobile app on iOS has a long-running bug where if you don’t open your app during the hike and you manage to run the battery down to zero…it tracks none of the steps or the mileage. It’s not the only way I’m tracking mileage, but it usually means I lose 4+ miles off the lifetime mileage which I think (because I’ve now done this half a dozen times already!) is going to add up over time and influence my ability to see where I am relative to the expected lifetime of the device. (This is an app issue they should be able to fix with software, they just haven’t yet). TL;DR for that part – the Ultra has a watch app where you can change settings AND see the battery, so I’d have more of a clue without having to pull my phone out to know when I’m getting close to the end of the battery and better plan for it so it doesn’t die halfway up a hilly stretch or that I remember to open the app before that happens.

I also wanted to do it as a motivation to get back out there and do a patented, Dana-and-Scott-special, which is what we jokingly call a chicken and fox adventure day (named after the river-crossing puzzle).

A chicken-and-fox adventure is something we started doing years ago, when I got into ultrarunning. Scott runs, but he doesn’t have the patience for long, flat runs like I do. He’d rather do long distance biking (which I have less patience for), or hike. So on long ultra training days, we’d drive out to the mountains somewhere and I’d pick a running route where Scott could drop me off and then go bike somewhere long and/or interesting, and we’d meet up at the end. Often, that turned into him dropping me off then parking the car at the end of the route, then he’d bike elsewhere, and I’d run my 20-30 miles to the car, grab the car, and drive to wherever his adventure ended and pick him up. Or vice versa with dropping him off at the start and then going for my run. We have had many awesome adventures like this, where “together” we are going out for really cool adventures even though we do them slightly differently, and we have great experiences to share with each other.

In the past year and a half or so…we haven’t had those adventures, because I haven’t been running, and I can’t ride my bike in the same way, and I didn’t feel confident hiking alone for very long. But, since August, my confidence began to grow after a lot of hiking (I’ve put 40,000 feet of elevation gain into my hikes between August and now, all with the Hypershell X Pro exoskeleton).

Thinking about the Hypershell X Ultra “Challenge” made me realize that I could – and wanted – to challenge myself to get back out and do a chicken-and-fox adventure.

The challenge I chose was a chicken and fox adventure on Rattlesnake Mountain (the one in western Washington state in the US)

The adventure I had in mind was a route I have always wanted to do, which is the full end to end Rattlesnake mountain hike. I’ve done parts of it – many people have, especially from Rattlesnake Lake to the Rattlesnake Ledges, which is a famous hike near Seattle that a lot of people do. Rattlesnake Ledges is one of our favorite places to take visitors, so we’ve actually done that twice this year. The other side of the mountain is also a good hike, although more about the wander through the forest. It starts at a mountain biking shared trailhead and meanders up to a few turnaround views (e.g. Grand Prospect) that also makes for a good out and back hike. If you want to hike the entire mountain, you need two cars…or you need someone who will do part of the hike, turn around and hike back down, drive around and meet you at the other side while you hike up and over the rest by yourself.

I had mentioned this hike / idea of an up and over several times, but the idea of hiking by myself made me nervous, especially with my physical abilities changing, because I sometimes need a hand getting up or down really steep, rocky terrain and I’m less sure-footed than most people. However, after ~250 miles of experience hiking with the Hypershell X Pro, my perspective was changing, and I was less nervous hiking in general *and* with the idea of hiking ~6-7 miles by myself up and over the mountain. So I pitched it to Scott and got him to agree to be the chicken* in our chicken-and-fox adventure day, with the plan of starting our hike on the Rattlesnake Ledges side, hiking up to the Ledges, then having him turn around and hike down and drive around to meet me on the other side…while I hiked from Rattlesnake Ledges up and over the remaining segments of the mountain trail by myself!

And that’s what we did (*although Scott claims he was the raft, as the car driver, rather than the chicken or the fox).

PS – if you’re in the area and doing the Rattlesnake Ledges hike, the “Ledges” you come to are actually the “first” ledges – there are two more ledge areas that you can hit! Yes, it’s more climbing, but only a few hundred feet between the ledges and the second ledges, and then up to the third ledges. There are really cool views at each set of ledges where you can see the other ledges, so it’s worth doing on some of your Ledges hikes.

What using the Ultra was like

Like I do for all my hikes, I got out of the car at the parking lot and put it on, which entails clipping the belt around my waist, clipping on each leg strap, and turning it on by pressing the button on the device. It auto-connects to the app and your phone without you having to open your phone each time (which is why, see above, I sometimes manage to run down an entire battery without having the app open so it doesn’t record the mileage in that scenario).

(Also like on most of my hikes, I made it 20 steps from the car before someone I walked by commented on the exoskeleton. It’s always really fun to be able to share with people, because often it’s people who have previous injuries or knee problems or other challenges who have heard about them, watched a video online, but never seen one in person before!)

Based on my experience using the Pro version, I know I like to do most of my flat or slightly uphill efforts on “eco” (green) mode at about 50% power. When I get to hillier sections, I’ll put it into “hyper” (red) mode and toggle the power up as needed for a bigger boost of power on lifting my legs as I climb, but for this hike with smooth terrain with more gradual climbs, I start on my personal defaults (eco, 50%). However, with the Ultra, the ‘re-engineered’ motors mean that the settings I use from my Pro don’t feel strong enough to assist me at the same level. I found myself bumping up to “eco” 75% to feel closer to what I experience with “eco” 50% on the Pro. (I thought maybe this was a one-off, but that does seem to hold true across a couple weeks of using it.)

Dana is hiking on a smooth trail through a forest, with light coming through the trees. She is wearing a small hiking vest/pack and wears a long sleeve black tshirt with dark purple leggings and you can just barely see the exoskeleton's dark straps against her from behind. Like using the Pro, having the Hypershell X Ultra makes it so I could do this full hike. It’s not a short hike: the full Rattlesnake Mountain hike is marked as 10.2 miles but from parking lot to parking lot it is closer to 10.9 miles and I tracked over 3,000 feet of elevation gain. I could do “just” the Rattlesnake Ledges hike (4.3 miles round trip, ~1100 feet of elevation gain), I could do the other side, but my muscles would be too fatigued to safely do a 10+ mile hike, so we wouldn’t even try it without an exoskeleton. And, there’s no way I would have considered doing it alone. Which…I did!

Scott hiked up with me to the main Rattlesnake Ledges (the ‘first’ ledges), and we took some pictures, then decided he would hike up with me to the next ledges as well. (In part because I estimated the hiking speed and he would be killing a lot of time waiting on me at the other side, and so he’d have more enjoyable views going up to the extra ledges than hiking through the forest without a view on the other side). We went up to the next ledges, and then he handed over my poles and headed back down the mountain, while I took off up the rest of the mountain…by myself!

Dana is a dark silhouette where you can see the sides of the exoskeleton's motors next to each hip, looking down at the sunlit valley with Rattlesnake Lake and Ledge ahead of her

(Earlier this year, I found that I needed to use hiking poles on uphill climbs to help me compensate for the very specific leg muscle function I was impaired by. But with the exoskeleton helping target lifting my leg, I have found that I rarely need poles going uphill anymore. Instead, we usually carry them folded up and bust them out of the backpack and use them for stability/confidence on downhill terrain. When Scott turned around, I still had another few thousand feet of elevation gain to go, so I didn’t need the poles, but I took them with me just in case and also so that I had them for the downhill side, which I would do solo.)

Dana is facing the camera, standing not very near the edge of the second ledge, with views of the dry Rattlesnake Lake and Rattelsnake Ledge behind her. It is a bright sunny day with the valley lit behind her.

We swapped batteries before Scott left, so that I had a fully charged battery for my solo segment. I think at the time I had used only ~40% of the first battery. In retrospect, I should’ve kept the other battery with me, but I didn’t (we put it in his backpack).

I hiked up all the way to East Peak, which is the farthest I had ever been up this side of the trail. I eventually crested onto a ridge where there was a logging area and really clear views on both sides – and the weather had cleared so I had several miles of visibility south to see areas that I had never seen before! I saw one trail runner pass me between this section and Grand Prospect, but otherwise I had over 4 miles solo with no one else in sight…and no concerns about my ability to cover the distance, alone, up in the mountains. Which was so, so, cool. (My only hesitation came with the occasional blowdowns of trees across the trails, one of which was a little challenging to climb over. Otherwise, it was smooth sailing along the trails by myself.)

I made it over to Grand Prospect and took a picture to document being there, because this marked the section of the trail I was familiar with. At this point, I still had 4 miles to go to the trailhead! Right after this, the trail began trailing downhill into the forest and this was where I was glad I had my poles, because although this trail is very smooth (as far as trails go), it had rained pretty heavily the previous two days and was muddy and slippery in a few places. Eventually, as I meandered down and was about 1.7 or so miles from the trailhead, I suddenly noticed my legs felt heavy. I looked down and…no lights. I had run down the full battery on the exoskeleton. Oops (see note above about my partially charged battery being with Scott). Luckily we had planned for Scott to hike up and meet me (rather than sitting around at the car), so I had less than 10 minutes before he reached me and we swapped the batteries back. Ahhhh, that felt so much better. (Although you don’t lift your legs as much on downhill terrain, you still lift your leg and that’s specifically where I have muscle impairment that is really aided by the exoskeleton, so it is night and day even on flat or downhill terrain for me when I use the exoskeleton versus walking without it. So I was glad to have my powered assist back on!)

We finished out the hike at the mountain biking shared trailhead, on the other side of Rattlesnake Mountain. I did it! I was so jazzed. I had been confident about the mileage and elevation, because since August I have done some other hikes in this ballpark of elevation gain and mileage, but it was really rewarding to feel confident enough to do that many miles up on a mountain ridge all by myself and feeling confident enough to deal with whatever situations would arise while hiking solo. And I would not, at this point in my situation, have done this without an exoskeleton.

I previously wrote about some of the benefits of using an exoskeleton, especially for hiking, but two months since writing that post, some of the specific aspects of using it that I wanted to highlight include:

I can step up and over things more easily. This could be stepping up onto a rock step, or up and over a branch on the trail. These things used to require poles more often; see above where now I very rarely need poles for the uphill even when stepping up and hiking up a long series of rock steps!
I also less often ‘need’ poles for downhill smooth terrain, like most of the Rattlesnake Ledges hike. I still like having them for trying to move quickly, or for wet/slippery terrain, or bigger step downs, but for rolling smooth terrain I often will go without for the downhill. I didn’t feel like that was even a choice before!
Because I can get my legs moving back at a reasonable pace for both flat walking and for hiking, I found that I can actually get a good cardiovascular workout again. Meaning, I used to be limited by my legs rather than my cardiovascular system, and my heart rate rarely was elevated and I couldn’t push myself because I was leg-limited. Now, I can actually walk briskly and raise my heart rate intentionally; same for hiking. This is huge for my overall health.
At the end of hikes and walks, because the rest of my muscles are less fatigued for compensating for the missing muscle action, I am rarely scuffing my feet at the end of walks and hikes the way I was pre-exoskeleton. I also have less fatigue in my muscles, even though I am going farther and longer and working my legs and my cardiovascular system harder! Pre-exoskeleton, I realized that I was limiting us to 8 mile hikes and then more commonly 4-6 mile hikes. Now, I’m back up to regularly wanting to choose 8-10 mile hikes on a regular basis. (And same for elevation: I had limited us down to ~2000 feet of elevation gain hikes for a while, because of fatigue concerns for the end of hikes, and now have no problem choosing >3,000 feet of elevation hikes again!)

All of this was in play during my challenge hike. I actually chose to do this long hike, alone, because I felt like I could do it. I got more physically out of the hike, because I was able to actually locomote and activate my cardiovascular system more, because I wasn’t wasting all my energy just moving my legs. I didn’t need my poles for going uphill. And I didn’t scuff my feet or trip on the entire hike, even though I was out there moving nonstop for 4 hours and 15 minutes!

What using the Ultra is like, compared to the Pro

Remember that my review/experience is skewed by having a lot of experience with the Hypershell X Pro. If you want to read my gushing about how exoskeletons are an instrument of freedom and the best thing since sliced bread for me lately – read my previous post about it. Otherwise, keep in mind this is mainly a comparison between the Pro and the Ultra, rather than never having used an exoskeleton then trying the Ultra.

You should take away from my first blog post (really, read it first if you haven’t!) and this one so far that exoskeletons are awesome and for people like me, they are a huge instrument of freedom. I never want to be without one, especially as long as I’m in whatever situation I’m in where my muscles work differently than they used to. That being said, I do see a lot of people asking online about the Ultra, the Ultra versus other models, etc, and I want to explain – from my perspective – what the differences are. And this needs a major caveat: my experience is 1) that of a person with some kind of condition that affects my leg muscles and 2) that of a person who personally bought and heavily used the Pro model before being given free access to the Ultra. Then read the below two sections because I’m going to give specific answers to what you should consider getting (or not) if you already have an exoskeleton versus what you should consider if you don’t already have one.

The difference between no exoskeleton and the Pro is probably 5x stronger than the difference between the Pro and the Ultra. The Ultra does have re-engineered motors supposedly causing it to be more efficient…but in my use case (which is likely different than the average person – remember my default ‘walking’ mode is eco 50% which is a lot higher than most people’s) I found that I had to bump the power up so much higher on the Ultra – to default eco 75% for just flat walking, and often 75% hyper mode for hills, too, then also often going up to 100% hyper for bigger hills. I rarely did that on the Pro. It is possible that I’m getting more mileage per battery, but I still don’t feel confident that it is because it’s more efficient or if they changed the power settings relative to each of those modes so I’m not using as much power as I was before. And while most people maybe wouldn’t notice that, I actually do. Because of how my leg muscles are specifically impaired, I can absolutely tell the difference between these. So I was less excited after using it, because of those factors for my unique situation.

The watch mode IS a game changer, though, for people like me who are busy hiking and not looking at our phones. It gives you a way to quickly turn adaptive mode on and off or switch between eco and hyper if you’re not familiar with the on-device button way of doing it (although it’s easy to learn: it’s a two second long press to switch you back and forth). But for me, the biggest benefit is having the watch app to show me the battery level! That helps me better see as I’m getting to the end of one battery as I often do, so I can remember to open my app (until they fix that bug) and also to look at where I am on the hike and decide if I want to go ahead and swap it out if I’m in the middle of a big steep section and don’t want to have to stop mid-climb when it suddenly dies. I did see a post somewhere that the watch app will eventually come to the other models (I hope so!), in which case this will also be a selling point for the other models rather than a differentiator for the Ultra. Update: as of early December 2025, the watch app now supports all models! So this is no longer a key differentiator.

The Ultra does look different: instead of orange and silver reflector material on the leg straps and waist belt, it is primarily black. The bars that extend down your legs are also black, because they’re the lighter carbon fiber material. I think aesthetically, the Ultra is a little more ‘subtle’ because of those color changes, especially when you’re wearing it against pants. In summer, when it’s against bare legs with shorts, I think it’ll be noticeable the same amount, but because I got access to the Ultra when I started wearing longer pants for hikes and walks this fall, it does feel like it’s less visually noticeable. Weight-wise, though, I don’t notice a difference from the carbon fiber material and the Ultra being slightly lighter overall weight than the Pro. This is something I actually considered about whether to buy the Pro versus the “Carbon” version originally..but I actually am not bothered by the Pro weight at all. The weight difference is maybe there, but because the Pro weight doesn’t phase me at all, it doesn’t feel like a big differentiator to me. However, I do see some people online who perceive the weight of the Pro to be a factor for them, so I’m guessing they’d benefit more from the lighter weight than I do.

Takeaways for those considering an exoskeleton if you don’t already have one

If you’re on the fence about getting an exoskeleton – yes, you should get one. Especially for those of us who have conditions that have changed our activity levels and patterns – it really is a game changer. The question shouldn’t be “should I get one” but “which one should I get”.

And based on my experience, I look at the math on battery, power output, and my experiences with both (see the chart on my previous post if you want to breakdown all the variables for the 3 main models outside of Ultra), and say…I still think the Pro is the best deal, for most people with the current pricing models.

The $200 difference is absolutely worth it for the higher output and second battery that you get with the Pro versus the lower “Go” model.
I chose the Pro originally because I didn’t think the main difference between the Pro and the Carbon, the weight difference, was worth $500. After using it for several months and after trying the carbon fiber (lighter weight) based Ultra, I still think that’s true.
I originally thought, before trying it, that maybe the extra mileage from the ‘re-engineered, more efficient motors’ on the Ultra would be worth it, so it would be a question between the $1200 Pro and the $2000 Ultra, with it being worth it IF you were someone like me who was really putting a lot of miles in and was regularly running down 1.5-2 full batteries per activity. But…after using it… in the current iteration, I don’t think that’s the case. (Again, my perspective might be skewed by ‘how high’ I run my default power levels, starting at eco 50% most of the time. So maybe that mileage boost is more for people who don’t by default use as much power as I do for all mileage. People who are fine with lower power output and are high mileage probably would like the Ultra.)
I still think most people are best suited by the “Pro” model. And if you’re like me and really putting the mileage in, it would be cheaper to get the Pro and later buy an extra battery or two than it would be to go for the Ultra. Unless you’re not like me and are a lower power need and also maybe someone who would notice the weight difference when wearing it.

TL;DR: you should absolutely get an exoskeleton. But, for most people, see above – go with the “Pro” unless you have specific reasons (e.g. lots of mileage and/or strongly preferring the slightly lighter weight of the device) to choose the Ultra.

Takeaways for those considering an Ultra if they already have another model

I think the same outline above applies here, which is that most people who have a Pro or a Carbon likely won’t benefit enough from the Ultra to justify an upgrade while theirs is still in good working order. I think the people who would benefit would be if you started on a “Go” model which only came with one battery and doesn’t put as much power out. Then, a switch to the Ultra is a reasonable shift for a second version exoskeleton, if you can afford it: otherwise going to the Pro gives you likely 90% of the benefit of the switch. However, a Pro to Ultra or a Carbon to Ultra doesn’t make as much sense until you wear down your existing exoskeleton and it reaches end of life, or you are someone with a Pro who really needs a lighter weight version and uses lower power output but still runs the battery down, in which case you might be the use case that is suited to the Ultra. But if you’re not in those situations, you may not have as much need to upgrade until your existing one reaches its end of life.

And who knows, maybe subsequent firmware and software upgrades will change the Ultra. If they manage to change the power levels back to something that better matches the Pro where I have more range to use the upper end of the power *and* get more mileage per battery? Then I will be a huge fan and encourage people to factor that into their decisions. But until then, see above.

—

Powered-exoskeleton-is-instrument-of-freedom-my-experience-Hypershell-X-Ultra-DanaMLewis TL;DR: I love exoskeletons, they’re an instrument of freedom. I paid $1,200 in August 2025 for a Hypershell X Pro exoskeleton and love it (still love it). In late October/early November, I was given for free a Hypershell X Ultra exoskeleton after being selected for the Hypershell X Ultra Product Explorer program and have been using it and comparing it for the last several weeks. I love the opportunity and appreciate being chosen in the explorer challenge program so I could try it, and because it motivated me to head out on a big chicken-and-fox adventure up and over the full length of Rattlesnake Mountain, which I wouldn’t be able or willing to do without an exoskeleton to support my adventuring.

A powered exoskeleton is an instrument of freedom – my experience with the Hypershell Pro X

August 23, 2025December 11, 2025 by Dana Lewis

Instruments of freedom are devices, tools, hacks or things that help us do more than we could otherwise, and often do more with less pain or hassle or risk.

Instruments of freedom can be small everyday things, like noise cancelling headphones that help you focus or an effective rolling suitcase that’s easier to roll through the airport. They can be anything that reduces the energy cost of doing something, or increases your comfort or confidence, or expands your choices and flexibility and independence. Instruments of freedom are for everyone, but they can be especially meaningful for people with various health conditions, especially those of us impacted by physical limitations as a result of these health conditions.

I first considered the framework of instruments of freedom a few years ago. A few years ago, my mindset went from “I don’t need poles” for hiking to “I wonder if poles might be beneficial”. I tried them, and they were immensely helpful. I didn’t know if it was because my balance and proprioception has changed ever since I broke my ankle (and later a toe), or if I would have benefited from them all along. Nevertheless, they were highly impactful for helping me power up and more confidently come down hills. As my body changed for other reasons (a new autoimmune disease affecting my lungs and muscles), poles went from optional to the only way I would be able to hike at all. But as hiking has become even harder, I have kept my eyes open for additional instruments of freedom that might be helpful. Specifically, for over a year and a half I have been wanting to try a lower body exoskeleton, but could not find one that was commercially (and easily) available, light enough, and at a price point that I was willing to pay.

Until now.

I discovered one called “Hypershell”. There were 3 versions available (“Go”, “Pro”, and “Carbon”) at the time I was evaluating them, with different price points ($999, $1199, $1799) with different features and accessories.

Here’s what the features were at the time I was evaluating them:

	Hypershell Go X	Hypershell Pro X	Hypershell Carbon X
Peak “Horsepower” output	0.5 HP (400W peak)	1 HP (800W peak)	1 HP (800W peak)
Motion Postures Recognized	6	10	10
Weight of device	2 kg	2 kg	1.8 kg
Battery range	~15 km (9 miles)	~17.5 km (10.5 miles)	~17.5 km (10.5 miles)
Temperature rating of battery	IP54 & Anti-Cold Down to −10 °C	IP54 & Anti-Cold Down to −20 °C	IP54 & Anti-Cold Down to −20 °C
Number of batteries included	1	2	2

(As I’m writing this in August 2025, note that they’re announcing a new “Ultra” model in September 2025 but it’s not clear yet what additional features or capabilities it will have.)

I wasn’t sure, though, if I would be able to use and benefit from the Hypershell. It’s hard to explain what my physical limitation is, but it results in me feeling like I can’t press off my ankle effectively (I wear ankle braces on both side) and there’s weakness in my thigh and hip, especially on the right side, that makes it hard to step up and over when going up the stairs and hiking. I can do it, but it’s exhausting, and it results in a weird sick-muscle type feeling after I do it a lot. I joined a Hypershell user group on Facebook and also the “Hypershell disability users” Facebook group. The second disability-based group kept cautioning that you needed to be able to lift up your foot 3-4 inches and take a step in order for the device to kick in. I was nervous about getting it and it not being able to work for me. But, there is a 2 week (14 day) return period, so I was hopeful that if it didn’t work I would be able to return it and get a refund. (But there were also not-so-great reviews of their customer service communication and the refund process, so I was nervous about that.)

I decided to get one and try it. I also specifically decided to choose the “Pro” model (see table above).

Why I chose a Hypershell Pro model instead of the Hypershell Go or Hypershell Carbon

The reasons I chose the “Pro”:

$200 difference from the base model (Go), but with the 10 motion patterns. Given that I’m hopeful that I can do more types of activities like I used to, I wanted to be able to have as much capability as possible.
More power output – the Go only has half as much peak power as the Pro/Carbon.
More range (mileage, albeit slightly)
Two batteries, including the better cold-resistant ones, on the Pro/Carbon instead of only 1 on the Go.
…but I didn’t care about the .2kg weight difference, and that was really the only difference between the Pro and Carbon. That wasn’t worth $500 between the Pro and the Carbon.

(Update – December 2025 – are you curious about the latest version, the Hypershell X Ultra? I was able to try one: here is a separate post about my experiences with the Hypershell X Ultra and my comparison to the Hypershell X Pro, with my Pro experiences described below.)

Unboxing the Hypershell exoskeleton and getting set up

Before the Hypershell arrived, I went ahead and downloaded the app. It required an email address and a password, and it also asked about height and weight. It had a decent onboarding experience in the app with videos embedded to show you how to open and get started and how to size it. The height and weight was used to give you a starting setting for the waist. But then I couldn’t do anything else in the app until I had connected the device.

When it arrived, I had low expectations for being able to use it right away, because people online talked about how long it took to charge/having a hard time charging it at first. Because of that, I expected to need to wait an hour or two of charge time before I used it and also was ready with a higher power wall plug to charge it. For some reason, the Hypershell batteries came (both) at 6% charge, but it was enough to turn on and get started for setting up the device. I was able to turn it on and get it connected in the app, do the onboarding (walking you through the first mode changes etc and taking test walks around the house in the different modes) even with it in 6% low battery status.

But then I took it off and put it on the charger to charge it up. I used the same wall plug I use for my laptop, and that was sufficient for its 65W charge rate. It takes a little over an hour to charge the 72 Wh battery up to full, and the lights on the device itself will show you (4 lights) when it’s fully charged, or you can see it in the app. It’s handy to have it lit up on the device because my husband, without access to the app, can see and change batteries to charge the next one himself.

A Hypershell Pro X model worn over grey loose-fitting pants. This is a side view, so you can see the motor against my hip, the bar as it wraps around toward the front bottom of my leg, and the knee strap. In terms of getting set up and putting it on, it’s very straight forward. It gave me a starting suggestion to use for the waist size. I used that (and have never changed it), tightened up the waist strap and leg straps, and it was good to go from there. Once I got the waist strap tightened, I haven’t had to re-tighten or change that. I have had to tweak the leg straps a little bit here and there, partially because of how it slides around on my leg (see below re: sweating, chafing, and wearing in the summer as opposed to wearing it over a layer of clothing), but it’s quick and easy to tighten the leg strap or loosen it when needed and not a big deal adjustment wise. I did read a few people saying it slips down their hips and they got suspenders to help, but I haven’t had that experience (I’m female, so I have plenty of hip bone for it to rest against, and maybe that’s in part what makes the difference?). The first time I put it on, because I was adjusting straps, I put it on while sitting at the edge of a chair and getting everything set up and tightened, then stood up and tweaked the straps, then turned it on and began using it. Now, I can grab it and put on the waist belt while standing, then slightly lean over and attach each leg strap (so I don’t have to sit down to put it on). Because it carries the battery in the back and the design also has the support bar around the back, it’s not really comfortable to sit with for long if you want to lean back against the back of the chair, but it’s fine if you’re sitting down briefly on something (a chair, a bench, etc) if you’re not trying to lean back or sit up against the back of anything.

My first time using the Hypershell Pro X

I was conservative with my first time using the Hypershell, in part because of users in various groups warning about taking it easy and not overdoing it. (If you have no disease/physical limitation as your reason for wanting to use this, you can probably ignore this.) After it charged fully, I put it on and went for a short mile and a half walk to see how it felt.

I knew from the onboarding experience (where it has you testing different modes) that I didn’t need “hyper” mode turned on to walk. “Eco” mode is the base mode, and you can adjust the power setting either on device (pressing a button twice increases it by 25%, triple pressing it drops it by 25%) or in the app with a slider that allows you to adjust it 5% increments.

I tried 25% power for my first walk, which was enough to feel the lift pulling my thigh and knee up. It felt so good! It made walking feel smooth and easy, especially on the right side where my thigh/hip muscles are more impaired. It felt like it made my walk more balanced in terms of not slogging along on the right side compared to my gait without assistance. I noticed a sensation of a few muscles feeling activation that normally aren’t getting activated (this is probably unique to my situation), but had no soreness or issues right after or the next day as a result of this test walk.

The next day, I did my normal length walk (of about 4 miles) with the Hypershell.

The third day? I took it hiking. And…(more about this below)

Small hiccups with adaptive mode recognition (that may be unique to my gait)

I had my app set to ‘adaptive motion recognition’, which is where it detects what you are doing (e.g. walking, going downhill or down stairs, idling, etc) and adjusts the assist based on the motion. It takes a step to kick in any assist and it takes about 2-3 steps into a new pattern (e.g., starting to go down the stairs) to swap modes. This means if I was walking toward the stairs and starting to go down the stairs, it would be the second or third step down where I would feel it change into downhill mode where I could feel it providing resistance against my thighs, as opposed to lifting my thighs as I stepped down. It was also very noticeable when I got to the landing and would take the 2-3 steps to turn the corner and continue down the flight of stairs. It would feel stiff-legged like I needed to tip toe to walk and then just as it switched to walk mode, I was going down the next flight of stairs and again it took 2-3 stairs before it was back on down hill mode. Not a big deal, but it did make me aware of it. I went down the stairs (carefully) while looking at the app which shows which motion pattern it is detecting, so I was able to see (and not just feel) that it was switching those modes and that’s why it suddenly felt different.

The other hiccup was when I was out walking on the sidewalk, which is flat. It was in walking mode and I was indeed walking, when suddenly it threw a stiff legged resistance at me. Huh?! I looked at the app and it showed “downhill” when I was walking on a flat surface. Weird. It reverted back to walk mode after 2-3 steps. It happened again later on my same walk. I must have something weird about my balance or gait that leans backward (?) or otherwise causes it to sense downhill, so it shifts to downhill mode. It didn’t trip me but it did make me go “woah” and I didn’t love it because I wanted to just be able to forget and walk without thinking about wearing it.

So as a result, I decided to turn off adaptive motion recognition and use it in ‘manual’ mode, rather than having it auto-detect. I’ve used it in “walking” mode ever since as my default mode, and it works great. It also still auto-detects and shows you what motion it detects in the app, but even with over a dozen miles of flat walking, it’s not thrown the downhill resistance in unexpectedly again. And, even in walking mode it still provides enough support and resistance for actually going down the stairs/downhill, regardless! So I get the same benefits without the risk of the sudden incorrect downhill resistance.

Kicking the tires of the Hypershell Pro X with hiking. A lot of hiking. Three days in a row!

Before using Hypershell, I could still hike. I used to hike three days in a row almost every week, but with this muscle disease, I found myself not being able to easily do it, so I would often hike Friday, rest and do something easier Saturday, then do another hike (maybe) on Sunday. This has been true for the last 6 months (or longer).

But my first hike with the Hypershell was on a Friday, and it went great. I played around with using the adaptive motion recognition and found that I couldn’t tell a big difference in the assist with ‘uphill’ mode versus ‘mountain climbing’ mode versus ‘walking’ mode. Downhill mode was good, but I also tested going downhill while in ‘walking’ mode and found it was good enough. Since all of these mode changes have to be done in the app, and the exoskeleton itself covers my pockets in a way that makes it hard to get my phone in and out of my pocket (plus I’m carrying poles), I decided I would try staying in ‘walking’ mode for everything from flat to uphill to downhill…and it did great. I felt so much more at ease stepping up and over steps and rocks and powering up hills the way I used to, and I also was thrilled that the little bit of resistance to my thighs for downhill made it easier to step and control my downsteps. All of this increased ease and control somehow resulted in me not generating the ‘sick muscle’ feeling I have been getting in my legs and glutes after hiking. In fact, I felt like I hadn’t been hiking at all! I was so thrilled that we decided we would hike again with it on Saturday, a second day in a row.

I did wake up with really tight calves on Saturday…but normal hiking tight calves, the way I used to get after the first few hikes of a new season when my calves are out of shape for climbing. I was thrilled because that meant that I was activating and using my legs MORE (despite the powered assistance of the exoskeleton!) on that first hike. Tightness and all, we decided we would hike again, and we actually chose a longer second-day hike with reasonable elevation now that I felt confident I could handle more of it with the exoskeleton. And I could: the second hike was also great, and I left it in ‘walking’ mode the entire time on the way up, but did find that I wanted to use higher power settings (still in eco) as a baseline and increase it further for hills. I think I used 30-40% as my base power, then would increase it more for bigger inclines. The nice thing is that for downhill, you are using less power, so even with ⅔ or so of the battery used up on my first and uphill half of the hike, I ended up at the bottom of the second hike with just above 10% battery left because the downhill uses so much less battery. (I had it in ‘downhill’ mode for the way down, where it provides resistance on the way down but when you’re on flats it’s not lifting your legs much as it would in walking mode.)

That went so well that…we headed out for a third day in a row. My first three-day weekend in a long time! Again, we chose a long hike with more elevation than we ever would have predicted would be possible for even a second day in a row, let alone a third day. This time, I was feeling more overall fatigue (hello, three days of hiking in a row!) and so I started with 50% power (eco mode) and cranked it up on hills. I finally remembered that I could adjust power with the button on the device, double clicking to add 25% as I went up a hill and triple clicking once I was on a flat (to decrease it back by 25%), without having to pull out my phone and open it and navigate to the app and slide the toggle. That made it easier, because I could still do that with poles in my hand.

Because I was cranking up the power more on this third day in a row, I did run out of battery on this hike. This was in part because there was a pretty steep climb on our return route about 2 miles from the end (of an 8.8 mile hike), and I wanted to crank the power all the way up to 100% (still on eco). I managed to get the battery down to 10% about halfway up that steep climb, and when it hits 10% it still goes but it definitely decreases the output. So we stopped and swapped to the second battery (that I had Scott carrying in his backpack). It’s quick and easy to pop off and swap (I let Scott do it). I powered it on and it instantly reconnected to the app, I put it back on 100%, and cranked my way up the rest of the hill with relative ease. Then I bopped the power back down to 50% for the rest of the hike. One of the reasons I ran down the first battery is because on the downhill/return portion, I kept it in “walking” mode for more assist rather than “downhill” mode. Again, three days in a row meant I was more tired overall and my legs were tired (but normal tired, not disease-tired), so I wanted the extra power to make sure I kept good form and didn’t cause injury by doing an atypical gait in my fatigue.

And I didn’t – I finished the hike, tired (normal tired) and with legs feeling in no way like we had hiked for three days, even though we did.

In three days in a row (which I can’t do without the Hypershell), we hiked 25 miles and over 6000 feet of elevation gain (which I wouldn’t be able to do without the Hypershell).

Instrument of freedom, indeed.

A view of me walking on a trail through an alpine meadow (green grass, flowers) with the mountain I hiked in the background and bright sun against a clear blue sky. I'm on the trail through the meadow and at first glance you may not notice it, but if you look you'll see black straps above the knee, which is the Hypershell strap, and you can also see the bar that goes around the back of my hips with the black battery, and you can also see the motors on the sides of my hips. But at a glance, you may not even notice it. — A view of me walking on a trail through an alpine meadow with the mountain I hiked in the background. At first glance you may not notice it, but if you look you’ll see black straps above the knee, which are the Hypershell straps, and you can also see the bar that goes around the back of my hips with the black battery, and you can also see the motors on the sides of my hips. But at a glance, you may not even notice it.

Did I keep the Hypershell Pro or did I return it? Is it worth it?

By the middle of the very first day of hiking, I knew I was keeping the Hypershell.

It works so well for me, and it really is an instrument of freedom for me. I love walking even on my flat paved trails with it, again because it makes my right hip and leg movement so much closer to what I used to experience (before my muscle disease).

Between my daily walks and the first two weekends of hiking, I have put around 60 miles on foot with the Hypershell Pro.

I’m definitely keeping it. It will be interesting to see if I run into any issues with my high-mileage use. The warranty is supposed to last for a year, and the website estimates ‘normal use’ service lifetime is 3000 km (1,900 miles). If I kept up my current pace of use (averaging 60 miles in two weeks) for a year, that would be around 1,560 miles, still under the expected lifetime use. I’d probably run into that life expectancy (which doesn’t mean it’ll stop working but might be when I expect it to run into issues) in about 14-15 months (or less if I increase my mileage).

But given how much it empowers me to move in the ways I want to move… it’s worth it. And I’m excited to see what other exoskeletons are coming to the market in the future, too. There may be more options for me to consider when this one eventually breaks or wears out.

Does it help with downhill or going down the stairs?

One of the things I really was hoping the Hypershell would help with is going downhill. I have trouble exerting power all the way through my foot, which is really noticeable when I am going downhill on looser dirt or rocks, where it feels like my foot is likely to slip sideways and cause me to jolt/lose my balance. As a result, my downhill hiking became as slow as the outbound uphill hikes (instead of faster, which is common for many people and the way it used to be for me) and made me really rely on my poles for balance. Plus it was super stressful and made hiking less fun, and I also skipped a lot of hikes that had a lot of rocky steps or rocky and loose rock downhill gravel terrain. But because of the Hypershell experience on my first hike, I actually chose a pretty rocky hike for the second hike because I was hopeful that it would help my sure-footedness. And it did! So much so that my second weekend of hiking, I chose a 9 mile hike with 3,100 feet of elevation gain that had a two mile stretch of loose rock and loose dirt with a good portion (1800 feet) of the downhill elevation. And I did great, with the Hypershell on.

But I didn’t know it would help when I got it. A lot of people talked about how it ‘didn’t help going down stairs’, so I had low expectations. When I went down stairs the first time, I didn’t notice a big difference, but when I hit the landing and took those 2-3 steps toward the next flight of stairs, I could feel that stiff legged feeling that definitely indicated it was providing resistance! So it was doing SOMETHING, but sometimes it was hard to tell what it was. Over time, with more experimentation on stairs and testing ‘downhill’ and ‘walking’ mode on different downhill terrains while hiking, I realized that I could feel the thigh-based resistance more strongly when in a higher power setting. The way it seems to work is it either provides some kind of down force against the leg as you are stepping down, or it provides resistance against your leg movement. I’m not quite sure which it is, but it results in a bit of pressure against your thigh, and probably some resistance on the sides (to limit lateral movement while stepping down), and it definitely helps me.

The other way I’ve figured out how to notice it is that with higher power modes while walking (and in walking mode), you can feel the lift ‘up’ from the thigh but depending on how quickly your leg is moving you can also feel the bar pushing back down into the down step. So the motor is able to move the bars (and thus your thighs) both up and down, and that’s likely also similar to what’s happening in downhill/stairs mode, but it’s less noticeable because you don’t lift your thigh as high (or at least, I don’t) when stepping down and it’s a much subtler force against your legs. But if you have stairs with landings, that’s a great place to put it in downhill mode and feel that type of sensation when you get to the landing and take a few steps before you do the next flight of stairs down.

There is also a setting you can adjust call “hill descent control” and once you toggle it on, you can adjust it between ‘weak’ and ‘strong’ (defaults to the middle of that range). I turned mine on but haven’t experimented with adjusting the slider to be stronger, but that may be another reason why I notice a benefit on downhills, whereas other people may not have turned that on.

Is it annoying to charge?

You have to charge the battery on the device itself (with a USB-C cord, and as I mentioned a beefy enough wall charger) or in a special hub that doesn’t come with it. The special hub can charge 4 batteries at once, off-device. Mine came with two batteries and since they charge up in an hour-ish, even if I run both batteries down and get home, it’s always going to be 12+ hours before I want to use it again and that’s plenty enough time to re-charge everything, even with swapping to the second battery to recharge.

I can see how if I went to having 3 batteries and using them regularly that I might want to also get the multi-battery charger, but for 1-2 batteries and my usage, it’s generally not a big deal.

Is there anything I don’t like about the Hypershell Pro X?

I have two (ok, three) issues with the Hypershell. All are minor.

For me, the adaptive motion recognition setting triggering ‘downhill’ when I am walking on a flat surface (albeit randomly and only occasionally) is annoying. Again, I don’t know if it is because of my gait or if there’s a bug in the pattern recognition. There is a workaround – putting it in ‘walking’ mode. I have found that it’s totally fine to keep it in ‘walking’ mode when going up or down stairs, up or down hills, on varying terrain, on flat surfaces. It still provides the lift to pull my thigh up just fine, and it also does the ‘resistance’ force for downhill and down stairs the same (or very similar) to the actual downhill setting. If I want to do more, I can easily turn the power up or down using the on-device button and get more force (for either lifting or resisting), and that is faster than trying to swap modes on my phone.

The second issue is chafing against bare skin. Ohhh, the chafing. You’ll notice that all of the pictures on their website and videos are of people wearing it over pants for winter-type activities. Some people hike in pants during the summer, but I got mine in July and I don’t wear long pants to walk or hike, so the straps around my thighs are against bare skin. I didn’t have any issues for the first few walks (which were all around an hour) but my first hike, which was 3 hours, caused some chafing. So on the second day, I covered those spots with bandaids. It wasn’t enough, I ended up with more chafing spots. So on the third day, I tried putting kinesio tape on my legs where I thought spots would chafe or were already chafed. That did help, but because I’m hiking so long (3-4 hours, multiple days in a row), just like ultrarunning in dealing with pack chafing, it’s hard to deal with once you have chafed spots.

The second week, I tried additional solutions. First I tried wrapping the pads themselves with “adhesive bandages” (think ‘vet wrap’, the stretch stuff that can stick to itself). I was trying to see if just covering the back of the front thigh pad would work, because there are seams underneath it. That helped some, but the force of the corner of the pad itself was chafing. I then bought a roll of 5 inch “tubular bandages”. I got 5” because I have more muscular thighs and I wanted to try putting a piece on my leg like a leg sleeve, and then having the pads against that, so it would rub against the bandage and not my skin. It helped some, but it was still digging in at the corners. So then I tried the leg bandage sleeve AND adding a layer of that material over the pad, double wrapping it at the corners. It helped some. But again, because I already had chafing, I don’t quite know what would work best to completely prevent or eliminate chafing. (I also have tried a 4 inch tubular bandage that was black, to better blend in with the leg strap, because the 5″ worked well but really popped in color and drew the eye to my legs, whereas the black better matches the leg bars and leg straps. In terms of functionality, I like the 5″ tan color better for using as a leg sleeve actually on my leg, so I’ll probably use that as a base layer if I’m not taping as described below when I’m not actively chafed, and then use the black on top of the leg pads and around the buckles directly.)

The next thing I have tried is hydrocolloid bandages (example, there are a lot of different brands and sizes and I’ve found no difference between name brand and off brand versions) on top of the biggest already-chafed spots, with the idea that it will provide cushion and also the pad corners will be more likely to slip on that versus digging in at the exact same spot. Because hydrocolloid (“blister” bandages) stick directly on the skin, I added a bit of neosporin on top of the chafing before applying, so that the bandages don’t stick to the slightly raw skin. The challenge with hydrocolloid bandages is that they take up any fluid, like blister fluid, but also sweat – so as you get sweaty, they’re more prone to peeling up or getting rubbed off via the edges. If you have a big enough bandage that’s less of an issue, but don’t expect to be able to cover a tiny area with a tiny hydrocolloid bandage and not have it peel up from the friction of the leg strap/pad itself or have it start to come off from sweat. I also tried applying larger strips of kinesio tape on top of the hydrocolloid bandages that are smaller, and the hydrocolloid seems to provide a nice cushion against the already chafed spots and the kinesio tape helps prevent it from rubbing the hydrocolloid bandage off.

It’ll be better in winter, when I’m wearing it on top of a layer of pants, and it’s not a reason to stop using it. In fact, most people probably won’t wear it long enough even in hot weather to experience it, but I wanted to document some of the solutions I tried in case anyone else does run into it.

UPDATE: the best solution I found is:

1) as soon as I notice the chafing begin in any spot, I stop and put a strip of kinesio tape in that area. (I pre-cut kinesio tape strips and carry them in my pack).

2) if I miss preventing a chafing spot and something has rubbed, I do a combined strategy of first putting a piece of hydrocolloid tape (I bought a roll so I could cut strips rather than using bandaid-sized – it’s cheaper and easier to apply different shapes) AND then putting a piece of kinesio tape over it. Why? Because as noted above, the hydrocolloid will collect sweat and fluid under the skin and start to come up during an activity, unless it’s anchored – and it’s best to do that when you apply it. That double strategy (hydrocolloi+kinesio, applied when your skin is dry) lasts for several days or longer (I’ve had it last up to a full week, even with multiple showers per day and using the exoskeleton every day), and it both heals up the chafed raw spots and protects subsequent spots from building up. So that’s a great solution during multi-hour bare-legged hike/activity season.

We’ve now also gotten to fall and I can confirm that chafing is not an issue at all when wearing it over long pants.

The third minor issue is accessing my pockets. The motor is on the outside of my hips and although the bars curve around down the front of my thighs, the access to my side pockets on my shorts is blocked. This is where I typically store fast-acting carbs on one side (because I have type 1 diabetes) and my phone on the other side, but I basically have to stop walking and pause and really finagle my hand in under the motor and bar to access something in my pocket. It’s annoying, so I actually stopped carrying my phone in my pocket while wearing it. I decided to get a phone carrying case that mounts to a backpack strap – or in my case, a Hypershell waist strap! It lives on the strap and I’m able to slip my phone into the 4 corners whenever I want to. I also like that the webbed strap comes out of the case, so I can pull my phone off it and use it (while it’s still in the straps) and then quickly put it back on the belt mount. There’s a little more friction to the experience than without the Hypershell, but it’s 5x easier than finagling my phone out of my pocket under the Hypershell.

If you want a referral code for a Hypershell, here is a referral code.

Right after I bought my Hypershell, I automatically got an email for a referral program. If you use this code, and you buy a Hypershell, it gets you $30 off. It’s not a lot, but it’s better than nothing. Sometimes they run deals where you can get accessories for free or some dollars off particular accessories. The ones I’ve seen are usually for more than the value of the referral code – e.g. they might offer an additional battery which is a $99 value instead of the $30 off. Depending on your situation, you may like one or the other better. I mention it because it doesn’t seem like it’s compatible to use the $30 off referral code at the same time as the other deals (or it wasn’t at the time that I tried to use someone else’s referral code at the time of my purchase).

Referral code (click this to generate the $30 off code which you use at checkout on Hypershell’s site): https://hypershelltechglob.refr.cc/referral30/u/danalewis

Should you get a Hypershell? Why or why not?

My experiences above are as someone living with an autoimmune disease that is affecting my muscles. But now that I’ve gotten it and tried it, I think I would love it even without the need for assistance with my muscle disease. Why? It’s like an e-bike for the legs. Not in the sense that it can do all the work (it can’t, it can only provide up to 20-30% assistance: you’re still doing a lot of work), but because it is an equalizer.

My husband and I have had e-bikes for years. We loved them, because of the equalizing effect. I can bike longer with e-bikes than I would without an e-bike. In fact, before we got e-bikes, we didn’t have bikes and would only sporadically ride (rentals), because biking wasn’t my thing. When we got e-bikes, we biked for dozens of miles at a time, together. I could bike at whatever power assist level I needed or wanted for the day, and he could use less assist and get more of a workout, but it enabled us to bike together (and to WANT to bike together) in ways that we couldn’t or wouldn’t otherwise.

An exoskeleton is the same situation, roughly, as e-biking in this sense. I talk to several people who ask questions when I’m out walking or hiking with the Hypershell on. Sometimes people ask about it for bad knees (I don’t have knee problems but I can imagine it would help – if you have knee issues and Hypershell experience, please share in a comment below!), but a few people have asked about it for backpacking experiences. One couple immediately said “I wonder if this would help for backpacking” and I said probably, yes – because the company advertises it to be able to do more for longer, especially with gear (e.g. they show people hiking with photography gear or big backpacks). So even without medical conditions, I could see getting a lot of use out of it when you have a pair of people who have different capabilities or range who want to go adventuring together. Especially if you’re a set of people (or an individual) who like to put in a lot of miles throughout the year…just like I am. I’ve already done 5 hikes in two weeks (plus a bunch of paved walks) and just hiking alone, that takes the per-hike cost down to $240, and will drop further each time I use it – remember that I wouldn’t have done some of these hikes at all (either because I couldn’t do them in subsequent days or I couldn’t do particular terrain at all). That per-hike cost will continue to drop over the course of the year (or more) of use that I expect to get out of this Hypershell Pro X.

How much work are you really doing when you wear a Hypershell exoskeleton? Doesn’t it do all the work for you?

Each of the two Hypershell batteries I have are 72 Wh (5000 mAh). That’s…actually not that much. It’s the equivalent to ~62 kcal if you’re thinking about food calories as a comparison. If you could continuously run the motors at full power, it would d only last 5-6 minutes. (That’s why I ran it down fast on 100% power on a really steep hill at the end of my third hike). With less power output, it goes longer time/mileage (e.g. the around 10 miles range estimation on lower power setting in eco mode), but it’s still only 62 calories of total energy, whereas I might be burning the equivalent of 1000+ calories of active energy in the course of a 3-4 hour hike. Yes, it provides power, but it’s targeted power to your legs (and there’s also heat loss), and you do a LOT of other work controlling your trunk, hips, core, arms, balance, etc. so it maybe contributes to 10-20% of energy savings. But again, you’re likely to do more – remember the e-bike analogy – and burn a lot more than you would without the Hypershell by doing more, well above and beyond anything you saved by using the Hypershell. You still do 90% of the work, for longer time and longer mileage and more elevation, resulting in more effort overall. You will still do plenty of work, but it will be easier to go further, longer, etc.

—

TLDR: I got a Hypershell Pro, I love it, and it’s enabling me to do more than I could before (in my unique situation with a muscle-related autoimmune disease). I do recommend it, for a variety of different situations, whether or not you have any physical limitations. It’s an instrument of freedom for anyone who wants it.

Feel free to ask any questions below. I can’t answer questions specifically about whether it would work for your specific setup or medical condition, but I can try my best to generalize from my experience & what I’ve read from others online.

PS – are you curious about the latest version, the Hypershell X Ultra? I was able to try one, and here’s a separate post about my experiences with the Hypershell X Ultra and my comparison to the Hypershell X Pro.

Powered exoskeleton is an instrument of freedom (my experience with a Hypershell Pro X), a blog by Dana M. Lewis on DIYPS.org

DIYPS.org

#WeAreNotWaiting to make the world a better place

Dana Lewis

Want signal? We need more noise (more examples to address the quiet bottleneck)

Want signal? We need more noise (looking at the quiet bottleneck)

The data we are leaving behind in clinical trials, what it costs us, and why we should talk about it

Which LLMs and how I am using them as of February 2026 plus a remote LLM prompting tool

Software-Shaped Feelings

Baseline Pilot – a leading indicator for biometric data and tool for reducing infection spread

BookPilot: What Should I Read Next?

What you shouldn’t take away from my talk about patient experiences of using AI in clinical healthcare

Chicken, foxes, rattlesnakes, and the Hypershell X Ultra

A powered exoskeleton is an instrument of freedom – my experience with the Hypershell Pro X

Recent Posts

Recent Comments

Archives

Categories

Meta