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, 2026January 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 – 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!) Update: I have heard from several folks already that they might be interested, so I have on my list to tidy this up a bit and push it to Github! If you want me to ping you once it goes up, drop a comment below or email me or ping me on Twitter or BlueSky.

* 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!

AI is often an accessibility tool, even if you don’t use it that way

May 29, 2025August 23, 2025 by Dana Lewis

Talking about AI (artificial intelligence) often veers conversations toward lofty, futuristic scenarios. But there’s a quieter, more fundamental way AI is making a big difference today: serving as an accessibility tool that helps many of us to accomplish tasks more efficiently and comfortably than otherwise would be possible. And often, enabling us to complete tasks we might otherwise avoid or be unable to do at all.

One way to think about AI is as the ultimate translator. But I don’t just mean between languages: I mean between ways of interacting with the world.

Imagine you’re someone dealing with a repetitive stress injury like carpal tunnel syndrome, making prolonged typing painful or even impossible. Traditionally, you might use dictation software to turn spoken words into text, alleviating physical strain. No issues with that, right? But somehow, suggesting people use AI tools to do the same thing (dictation and cleaning up of the dictated text) causes skepticism about “cheating” the “correct” way of doing things. If you imagine the carpal tunnel scenario, that’s less likely to be a reaction, but imagine many other situations where you see outrage and disgust (as a knee jerk reaction) to the idea of people using AI.

In reality, there are three ways of doing things to accomplish a note-taking task:

A human types notes
A human speaks notes to a voice dictation tool
A human speaks notes to an AI-based dictation tool, that also when prompted could clean up and transform the notes into different formats.

All three introduce the possibility of errors. The difference is how we perceive and tolerate those errors: the perception often reflects bias rather than logic.

For example, the focus disproportionately in the third example is about errors, where errors might not even come up in the other two. OMG, the AI might do something wrong! It might hallucinate an error! Well, yes, it might. But so too does the dictation software. There was similar outrage years ago when voice dictation software became common for doctors to use to dictate their chart notes. And yes, there were and are errors there, too. And guess what? Humans typing notes? ALSO RESULTS IN ERRORS. The important thing here is all three cases: human alone, human plus basic tech, human plus AI, all result in the possibility of errors.

(I actually see this frequently, where I see three different providers who either use voice dictation to write my chart notes, introducing errors; AI-assisted notetaking, occasionally introducing errors; and one manually types all of their notes…still occasionally introducing errors. They’re typically different types of errors, but the result is the same: error!)

This is more about cultural change than it is about the errors in and of themselves. If people actually cared about the errors, we would be creating pathways to fix errors by humans and other approaches, such as enabling wiki-style editing requests of medical charts so that patients and providers can collaboratively update and keep medical records and chart notes free of errors so they don’t propagate over time. This almost never happens: chart notes can only be corrected by providers, and patients often have to use scarce visit time if they care enough to request a correction. Instead, most discussions focus more on where theoretical errors came from rather than practical approaches to fix real-world errors.

Back to AI specifically:

Note taking is a simplistic example of what can be useful with AI, but there’s more examples of transformation, such as transforming data into different formats. Converting data from JSON to CSV or vice versa – this is a task that can be tedious or impossible for some people. Sure, this could be done manually, or it can be done with hand-written scripts for transforming the data, or it can be done by having an AI write the scripts to transform that data, or it can be done with the AI writing and executing the scripts to “transform the data itself”. AI can often do all of these steps quickly and efficiently, triggered by a plain-language request (either typed or dictated by voice).

Here are other examples where AI can be an accessibility tool:

A visually impaired user has AI describe images and generate ALT text and/or convert unreadable PDFs into something their screen reader can use. They might also have the AI summarize the text, first, to see if they want to bother spending the time screen reading all that text.
Individuals with mobility limitations control their home environment or work environment, by using AI to pair together tools that allow them to do things that weren’t possible before, and can brainstorm solutions to problems that previously they didn’t know how to solve or didn’t have the tools to solve or build.
People in a country where they don’t speak the language and are needing to access the healthcare system can benefit from real-time AI translation when there’s no medical interpreter services, if they bring their own AI translator. US healthcare providers are generally prohibited from using such tools and are forced to forego translation entirely when human translators are not available.
People with disabilities (whether those are mental or physical) using AI to help understand important healthcare or insurance forms or paperwork they need to understand or interpret and take action on.

Personally, I keep finding endless ways where AI is an accessibility tool for me, in large and small ways. And the small ways often add up to a lot of time saved.

One frequent example where I keep using it is for finding and customizing hikes. Last year, I had to change my exercise strategy, which included hiking more instead of running. Increasingly since then, though, I also have had to modify which hikes I’m able to do, including factoring in the terrain. (Super rocky or loose rock terrain are challenging whereas they used to not be a limitation). I used to spend a lot of time researching hikes based on location, then round trip distance, then elevation gain, then read trail descriptions and trail reports from recent weeks and months to ensure that a hike would be a good candidate for me. This actually took quite a bit of time to do manually (for context, we did 61 hikes last year!).

But with AI, I can give an LLM the parameters of geography (eg hikes along the I-90 corridor or less than two hours from Seattle), round trip mileage and elevation limits, *and* ask it to search and exclude any hikes with long sections of loose, rocky or technical terrain. I can also say things like “find hikes similar to the terrain of Rattlesnake Ledge”, which is a smooth terrain hike. This cuts down and creates a short list that meets my criteria so I can spend my time picking between hikes that already meet all my criteria, and confirming the AI’s assessment with my own quick read of the trail description and trail reviews.

It’s a great use of AI to more quickly do burdensome tasks, and it’s actually found several great hikes that I wouldn’t have found by manual searching, which is expanding my ‘horizons’ even when it feels like I’m being limited by the increasing number of restrictions/criteria that I need to plan around. Which is awesome. As hiking itself gets harder, the effort it takes to find doable hikes with my new criteria is actually much less, which means the cost-effort ratio of finding and doing things continues to evolve so that hiking continues to be something I do rather than giving it up completely (and drastically reducing my physical activity levels).

Whenever I see knee jerk reactions along the lines of “AI is bad!” and “you shouldn’t use it that way!” it often comes from a place of projecting the way people “should” do things (in a perfect world). But the reality is, a lot of times people can’t do things the same way, because of a disability or otherwise.

AI is an accessibility tool, even if you do not use it that way). A blog by Dana M. Lewis from DIYPS.org AI often gives us new capabilities to do these things, even if it’s different from the way someone might do it manually or without the disability. And for us, it’s often not a choice of “do it manually or do it differently” but a choice of “do, with AI, or don’t do at all because it’s not possible”. Accessibility can be about creating equitable opportunities, and it can also be about preserving energy, reducing pain, enhancing dignity, and improving quality of life in the face of living with a disability (or multiple disabilities). AI can amplify our existing capabilities and super powers, but it can also level the playing field and allow us to do more than we could before, more easily, with fewer barriers.

Remember, AI helps us do more – and it also helps more of us do things at all.

The data we leave behind in clinical trials and why it matters for clinical care and healthcare research in the future with AI

May 28, 2025 by Dana Lewis

Every time I hear that all health conditions will be cured and fixed in 5 years with AI, I cringe. I know too much to believe in this possibility. But this is not an uninformed opinion or a disbelief in the trajectory of AI takeoff: this is grounded in the very real reality of the nature of clinical trials reporting and publication of data and the limitations we have in current datasets today.

The sad reality is, we leave so much important data behind in clinical trials today. (And every clinical trial done before today). An example of this is how we report “positive” results for a lot of tests or conditions, using binary cutoffs and summary reporting without reporting average titres (levels) within subgroups. This affects both our ability to understand and characterize conditions, compare overlapping conditions with similar results, and also to be able to use this information clinically alongside symptoms and presentations of a condition. It’s not just a problem for research, it’s a problem for delivering healthcare. I have some ideas of things you (yes, you!) can do starting today to help fix this problem. It’s a great opportunity to do something now in order to fix the future (and today’s healthcare delivery gaps), not just complain that it’s someone else’s problem. If you contribute to clinical trials, you can help solve this!

What’s an example of this? Imagine an autoantibody test result, where values >20 are considered positive. That means a value of 21, 58, or 82 are all considered positive. But…that’s a wide range, and a much wider spread than is possible with “negative” values, where negative values could be 19, 8, or 3.

When this test is reported by labs, they give suggested cutoffs to interpret “weak”, “moderate”, or “strong” positives. In this example, a value of 20-40 is a “weak” positive, a value between 40-80 is a “moderate” positive, and a value above 80 is a strong positive. In our example list, all positives actually fall between barely a weak positive (21), a solidly moderate positive in the middle of that range (58), and a strong positive just above that cutoff (82). The weak positive could be interpreted as a negative, given variance in the test of 10% or so. But the problem lies in the moderate positive range. Clinicians are prone to say it’s not a strong positive therefore it should be considered as possibly negative, treating it more like the 21 value than the 82 value. And because there are no studies with actual titres, it’s unclear if the average or median “positive” reported is actually all above the “strong” (>80) cutoff or actually falls in the moderate positive category.

Also imagine the scenario where some other conditions occasionally have positive levels of this antibody level but again the titres aren’t actually published.

Today’s experience and how clinicians in the real world are interpreting this data:

21: positive, but 10% within cutoff doesn’t mean true positivity
53: moderate positive but it’s not strong and we don’t have median data of positives, so clinicians lean toward treating it as negative and/or an artifact of a co-condition given 10% prevalence in the other condition
82: strong positive, above cutoff, easy to treat as positive

Now imagine these values with studies that have reported that the median titre in the “positive” >20 group is actually a value of 58 for the people with the true condition.

21: would still be interpreted as likely negative even though it’s technically above the positive cutoff >20, again because of 10% error and how far it is below the median
53: moderate positive but within 10% of the median positive value. Even though it’s not above the “strong” cutoff, more likely to be perceived as a true positive
92: still strong positive, above cutoff, no change in perception

And what if the titres in the co-condition have a median value of 28? This makes it even more likely that if we know the co-condition value is 28 and the true condition value is 58, then a test result of 53 will be more correctly interpreted as the true condition rather than providing a false negative interpretation because it’s not above the >80 strong cutoff.

Why does this matter in the real world? Imagine a patient with a constellation of confusing symptoms and their positive antibody test (which would indicate a diagnosis for a disease) is interpreted as negative. This may result in a missed diagnosis, even if this is the correct diagnosis, given the absence of other definitive testing for the condition. This may mean lack of effective treatment, ineligibility to enroll in clinical trials, impacted quality of life, and possibly negatively impacting their survival and lifespan.

If you think I’m cherry picking a single example, you’re wrong. This has played out again and again in my last few years of researching conditions and autoantibody data. Another real-world scenario is where I had a slight positive (e.g. above a cutoff of 20) value, for a test that the lab reported is correlated with condition X. My doctor was puzzled because I have no signs of this condition X. I looked up the sensitivity and specificity data for this test and it only has 30% sensitivity and 80% specificity, whereas 20% of people with condition Y (which I do have) also have this antibody. There is no data on the median value of positivity in either condition X or condition Y. In the context of these two pieces of information we do have, it’s easier to interpret and guess that this value is not meaningful as a diagnostic for condition X given the lack of matching symptoms, yet the lab reports the association with condition X only even though it’s only slightly more probably for condition X to have this autoantibody compared to condition Y and several other conditions. I went looking for research data on raw levels of this autoantibody, to see where the median value is for positives with condition X and Y and again, like the above example, there is no raw data so it can’t be used for interpretation. Instead, it’s summary of summary data of summarizing with a simple binary cutoff >20, which then means clinical interpretation is really hard to do and impossible to research and meta-analyze the data to support individual interpretation.

And this is a key problem or limitation I see with the future of AI in healthcare that we need to focus on fixing. For diseases that are really well defined and characterized and we have in vitro or mouse models etc to use for testing diagnostics and therapies – sure, I can foresee huge breakthroughs in the next 5 years. However, for so many autoimmune conditions, they are not well characterized or defined, and the existing data we DO have is based on summaries of cutoff data like the examples above, so we can’t use them as endpoints to compare diagnostics or therapeutic targets. We need to re-do a lot of these studies and record and store the actual data so AI *can* do all of the amazing things we hear about the potential for.

But right now, for a lot of things, we can’t.

So what can we do? Right now, we actually CAN make a difference on this problem. If you’re gnashing your teeth about the change in the research funding landscape? You can take action right now by re-evaluating your current and retrospective datasets and your current studies and figure out:

Where you’re summarizing data and where raw data needs to be cleaned and tagged and stored so we can use AI with it in the future to do all these amazing things
What data could I tag and archive now that would be impossible or expensive to regenerate later?
Am I cleaning and storing values in formats that AI models could work with in the future (e.g. structured tables, CSVs, or JSON files)?
Most simply: how am I naming and storing the files with data so I can easily find them in the future? “Results.csv” or “results.xlsx” is maybe not ideal for helping you or your tools in the future find this data. How about “autoantibody_test-X_results_May-2025.csv” or similar.
Where are you reporting data? Can you report more data, as an associated supplementary file or a repository you can cite in your paper?

You should also ask yourself whether you’re even measuring the right things at the right time, and whether your inclusion and exclusion criteria are too strict and excluding the bulk of the population for which you should be studying.

An example of this is in exocrine pancreatic insufficiency, where studies often don’t look at all of the symptoms that correlate with EPI; they include or allow only for co-conditions that are only a tiny fraction of the likely EPI population; and they study the treatment (pancreatic enzyme replacement therapy) without context of food intake, which is as useful as studying whether insulin works in type 1 diabetes without context of how many carbohydrates someone is consuming.

You can be part of the solution, starting right now. Don’t just think about how you report data for a published paper (although there are opportunities there, too): think about the long term use of this data by humans (researchers and clinicians like yourself) AND by AI (capabilities and insights we can’t do yet but technology will be able to do in 3-5+ years).

A simple litmus test for you can be: if an interested researcher or patient reached out to me as the author of my study, and asked for the data to understand what the mean or median values were of a reported cohort with “positive” values…could I provide this data to them as an array of values?

For example, if you report that 65% of people with condition Y have positive autoantibody levels, you should also be able to say:

The mean value of the positive cohort (>20) is 58.
The mean value of the negative cohort (<20) is 13.
The full distribution (e.g. [21, 26, 53, 58, 60, 82, 92…]) is available in a supplemental file or data repository.

That makes a magnitude of difference in characterizing many of these conditions, for developing future models, testing treatments or comparative diagnostic approaches, or even getting people correctly diagnosed after previous missed diagnoses due to lack of available data to correctly interpret lab results.

Maybe you’re already doing this. If so, thanks. But I also challenge you to do more:

Ask for this type of data via peer review, either to be reported in the manuscript and/or included in supplementary material.
Push for more supplemental data publication with papers, in terms of code and datasets where possible.
Talk with your team, colleague and institution about long-term storage, accessibility, and formatting of datasets
Better yet, publish your anonymized dataset either with the supplementary appendix or in a repository online.
Take a step back and consider whether you’re studying the right things in the right population at the right time

The data we leave behind in clinical trials (white matters for clinical care, healthcare research, and the future with AI), a blog post by Dana M. Lewis from DIYPS.org These are actionable, doable, practical things we can all be doing, today, and not just gnashing our teeth. The sooner we course correct with improved data availability, the better off we’ll all be in the future, whether that’s tomorrow with better clinical care or in years with AI-facilitated diagnoses, treatments, and cures.

We should be thinking about:

What if we design data gathering & data generation in clinical trials not only for the current status quo (humans juggling data and only collecting minimal data), but how should we design trials for a potential future of machines as the primary viewers of the data?
What data would be worth accepting, collecting, and seeking as part of trials?
What burdens would that add (and how might we reduce those) now while preparing for that future?

The best time to collect the data we need was yesterday. The second best time is today (and tomorrow).

Try, Try Again with AI

April 12, 2025 by Dana Lewis

If you’ve scoffed at, dismissed, or tried using AI and felt disappointed in the past, you’re not alone. Maybe the result wasn’t quite right, or it missed the mark entirely. It’s easy to walk away thinking, “AI just doesn’t work.” But like learning any new tool, getting good results from AI takes a little persistence, a bit of creativity, and the willingness to try again. Plus an understanding that “AI” is not a single thing.

AI is not magic or a mind reader. AI is a tool. A powerful one, but it depends entirely on how you use it. I find it helpful to think of it as a coworker or intern that’s new to your field. It’s generally smart and able to do some things, but it needs clear requests and directions on what to do. When it misses the mark, it needs feedback, or for you to circle around and try again with fresh instructions.

If your first attempt doesn’t go perfectly, it doesn’t mean the technology is useless, just like your brand new coworker isn’t completely useless.

Imperfect Doesn’t Mean Impossible

One way to think of AI is that it is a new kitchen gadget. Imagine that you get a new mini blender or food processor. You’ve never made a smoothie before, but you want to. You toss in a bunch of ingredients and out comes…yuck.

Are you going to immediately throw away the blender? Probably not. You’re likely to try again, with some tweaks. You’ll try different ingredients, more or less liquid, and modify and try again.

I had that experience when I broke my ankle and needed to incorporate more protein in my diet. I got a protein powder and tried stirring it into chocolate milk. Gross. I figured out that putting it in a tupperware container and shaking it thoroughly, then leaving it overnight, turned out ok. Eventually when I got a blender, I found it did even better. But the perfect recipe for me ended up being chocolate milk, protein powder, and frozen bananas. Yum, it made it like a chocolate milkshake texture and I couldn’t tell there was powder in it. But I still had to tweak things: shoving in large pieces of frozen bananas didn’t work well with my mini blender. I figured out slices worked ok, and eventually Scott and I zeroed in that it was most efficient to slice the banana and put it into the freezer, that way I had ready-to-go frozen right-sized banana chunks to mix in.

I had some other flops, too. I had found a few other recipes I liked to do without protein powder. Frozen raspberry or frozen pineapple + a crystal light lemonade packet + water are two of my hot weather favorites. But one time it occurred to me to try the pineapple recipe with protein powder in it… ew. That protein powder did not go well with citrus. So I didn’t make that one again.

AI is like that blender. If the result isn’t what you wanted, you should try:

Rewriting your prompt. Try different words, try giving it more context (instructions).
Give it more detail or clearer instructions. “Make a smoothie” is a little vague; “blend chocolate milk, protein powder, and frozen banana” is a little more direction to tell it what you want.
Try a different tool. The models are different for LLMs, and the setup is different for every tool. How you might use ChatGPT to do something might end up being different for using Gemini or MidJourney.

Sometimes, small tweaks make a big difference.

If It Doesn’t Work Today, Try Again Tomorrow (or sometime in the future)

Some tasks are still on the edge of what AI can do in general, or a particular model at that time. That doesn’t mean they’ll always be unable to do that task. AI is improving constantly, and quickly. What didn’t work a few months ago might work today, either in the same model or a new model/tool.

I’ve started making a list of projects or tasks I want to work on where the AI isn’t quite there yet and/or I haven’t figured out a good setup, the right tool, etc. A good example of this was when I wanted to make an Android version of PERT Pilot. It took me *four tries* over the course of an entire year before I made progress to a workable prototype. Ugh. I knew it wasn’t impossible, so I kept coming back to the project periodically and starting fresh with a new chat and new instructions to try to get going. In the course of a year, the models changed several times, and the latest models were even better at coding. Plus, I was better through practice at both prompting and troubleshooting when the output of the LLM wasn’t quite what I wanted. All of that over time added up, and I finally have an Android version of PERT Pilot (and it’s out on the Play Store now, too!) to match the iOS version of PERT Pilot. (AI also helped me quickly take the AI meal estimation feature from PERT Pilot, which is an app for people with EPI, and turn it into a general purpose app for iOS called Carb Pilot. If you’re interested in getting macronutrient (fat, protein, carb, and/or calorie) counts for meals, you might be interested in Carb Pilot.)

Try different tasks and projects

You don’t have to start with complex projects. In fact, it’s better if you don’t. Start with tasks you already know how to do, but maybe want to see how the AI does. This could be summarizing text, writing or rewriting an email, changing formats of information (eg json to csv, or raw text into a table formatted so you can easily copy/paste it elsewhere).

Then branch out. Try something new you don’t know how to do, or tackle a challenge you’ve been avoiding.

There are two good categories of tasks you can try with AI:

Tasks you already do, but want to do more efficiently
Tasks you want to do, but aren’t sure how to begin

AI is a Skill, and Skills Take Practice

Using AI well is a skill. And like any skill, it improves with practice. It’s probably like managing an intern or a new coworker who’s new to your organization or field. The first time you managed someone, it probably wasn’t as good as after you had 5 years of practice managing people or helping interns get up to speed quickly. Over time, you figure out how to right-size tasks; repeat instructions or give them differently to meet people’s learning or communication styles; and circle back when needed when it’s clear your instructions may have been misunderstood or they’re heading off in a slightly unexpected direction.

Don’t let one bad experience with AI close the door. The people who are getting the most out of AI right now are the ones who keep trying. We experimented, failed, re-tried, and learned. That can be you, too.

If AI didn’t wow you the first time for the first task you tried, don’t quit. Rephrase your prompt. Try another model/tool. (Some people like ChatGPT; some people like Claude; some people like Gemini….etc.) You can also ask for help. (You can ask the LLM itself for help! Or ask a friendly human, I’m a friendly human you can try asking, for example, if you’re reading this post. DM or email me and tell me what you’re stuck on. If I can make suggestions, I will!)

Come back in a week. Try a new type of task. Try the same task again, with a fresh prompt.

But most importantly: keep trying. The more you do, the better it gets.

iOS and Android development experience for newbies

April 8, 2025April 12, 2025 by Dana Lewis

Vibe coding apps is one things, but what about deploying and distributing them? That still requires some elbow grease, and I’ve described my experiences with both Apple and Google below for my first apps in each platform.

(I’m writing this from the perspective of someone familiar with coding primarily through bash scripts, JavaScript, Python, and various other languages, but with no prior IDE or mobile app development experience when I got started, as I typically work in vim through the terminal. I was brand new to IDEs and app development for both iOS and Android when I got started. For context, I have an iOS personal device.)

Being new to iOS app development

First, some notes on iOS development. If you only want to test your app on your own phone, it’s free. You can build the app in XCode and with a cord, deploy it directly on your phone. However, if you wish to distribute apps via TestFlight (digitally) to yourself or other users, Apple requires a paid developer account at $99 per year. (This cost can be annoying for people working on free apps who are doing this as not-a-business). Initially, figuring out the process to move an app from Xcode to TestFlight or the App Store is somewhat challenging. However, once you understand that archiving the app opens a popup to distribute it, the process becomes seamless. Sometimes there are errors if Apple has new development agreements for you to sign in the web interface, but the errors from the process just say your account is wrong. (So check the developer page in your account for things to sign, then go try again once you’ve done that.) TestFlight itself is intuitive even for newcomers, whether that is yourself or a friend or colleague you ask to test your app.

Submitting an app to the App Store through the web interface is relatively straightforward. Once you’ve got your app into TestFlight, you can go to app distribution, and create a version and listing for your app and add the build you put into TestFlight. Note that Apple is particular about promotional app screenshots and requires specific image sizes. Although there are free web-based tools to generate these images from your screenshots, if you use a tool without an account login, it becomes difficult to replicate the exact layout later. To simplify updates, I eventually switched to creating visuals manually using PowerPoint. This method made updating images easier when I had design changes to showcase, making me more likely to keep visuals current. Remember, you must generate screenshots for both iPhone and iPad, so don’t neglect testing your app on iPad, even if usage might seem minimal.

When submitting an app for the first time, the review process can take several days before beginning. My initial submission encountered bugs discovered by the reviewer and was rejected. After fixing the issues and resubmitting, the process was straightforward and quicker than expected. Subsequent submissions for new versions have been faster than the very first review (usually 1-3 days max, sometimes same-day), and evaluation by App Store reviewers seems more minimal for revisions versus new apps.

The main challenge I have faced with App Store reviews involved my second app, Carb Pilot. I had integrated an AI meal estimation feature into PERT Pilot and created Carb Pilot specifically for AI-based meal estimation and custom macronutrient tracking. Same feature, but plucked out to its own app. While this feature was approved swiftly in PERT Pilot as an app revision, Carb Pilot repeatedly faced rejections due to the reviewer testing it with non-food items. Same code as PERT Pilot, but obviously a different reviewer and this was the first version submitted. Eventually, I implemented enough additional error handling to ensure the user (or reviewer, in this case) entered valid meal information, including a meal name and a relevant description. If incorrect data was entered (identified by the API returning zero macronutrient counts), the app would alert users. After addressing these edge cases through several rounds of revisions, the app was finally approved. It might have been faster with a different reviewer, but it did ultimately make the app more resilient to unintended or unexpected user inputs.

Other than this instance, submitting to the App Store was straightforward, and it was always clear at what stage the process was, and the reviewer feedback was reasonable.

(Note that some features like HealthKit or audio have to be tested on physical devices, because these features aren’t available in the simulator, so depending on your app functionality, you’ll want to test both with the simulator and with physical iOS devices to test those. Otherwise, you don’t have to have access to test on a physical device.)

Being new to Android app development

In contrast, developing for Android was more challenging. I decided to create an Android version of PERT Pilot after receiving several requests. However, this effort took nearly two years and four separate attempts to even get a test version built. I flopped at the same stage three times in a row, even with LLM (AI) assistance in trying to debug the problem.

Despite assistance from language models (LLMs), I initially struggled to create a functional Android app from scratch. Android Studio uses multiple nested folder structures with Kotlin (.kt) files and separate XML files. The XML files handle layout design, while Kotlin files manage functionality and logic, unlike iOS development, which primarily consolidates both into fewer files or at least consistently uses a single language. Determining when and where to code specific features was confusing. (This is probably easier in 2025 with the advent of agent and IDE-integrated LLM tools! My attempts were with chat-based LLMs that could not access my code directly or see my IDE, circa 2023 and 2024.)

Additionally, Android development involves a project-wide “gradle” file that handles various settings. Changes made to this file require manually triggering a synchronization process. Experienced Android developers might find this trivial, but it is unintuitive for newcomers to locate both the synchronization warnings and the sync button. If synchronization isn’t performed, changes cannot be tested, causing blocks in development.

Dependency management also posed difficulties, and that plus the gradle confusion is what caused my issues on three different attempts. Initially, dependencies provided by the LLM were formatted incorrectly, breaking the build. Eventually (fourth time was the charm!), I discovered there are two separate gradle files, and pasting dependencies correctly and synchronizing appropriately resolved these issues. While partly user error (I kept thrashing around with the LLM trying to solve the dependency formatting, and finally on the fourth attempt realized it was giving me a language/formatting approach that was a different language than the default Android Studio gradle file, even though I had set up Android Studio’s project to match the LLM approach. It was like giving Android Studio Chinese characters to work with when it was expecting French), this issue significantly impacted my development experience, and it was not intuitive to resolve within Android Studio even with LLM help. But I finally got past that to a basic working prototype that could build in the simulator!

I know Android has different features than iOS, so I then had to do some research to figure out what gestures were different (since I’m not an Android user), as well as user research. We switched from swiping to long pressing on things to show menu options for repeat/edit/deleting meals, etc. That was pretty easy to swap out, as were most of the other cosmetic aspects of building PERT Pilot for Android.

Most of the heartache came down to the setup of the project and then the exporting and deploying to get it to the Play Store for testing and distribution.

Setting up a Google Play developer account was quick and straightforward, despite needing to upload identification documents for approval, which took a day to get verified. There’s a one-time cost ($25) for creating the development account, that’s a lot cheaper than the yearly fee for Apple ($99/year). But remember, above and below, that you’re paying with your time as opposed to money, in terms of a less intuitive IDE and web interface for moving forward with testing and deploying to production.

Also, you have to have hands-on access to a physical Android device. I have an old phone that I was able to use for this purpose. You only have to do this once during the account creation/approval process, so you may be able to use a friend’s device (involves scanning QR code and being logged in), but this is a little bit of a pain if you don’t have a modern physical Android device.

I found navigating the Play Store developer console more complicated than Apple’s, specifically when determining the correct processes for uploading test versions and managing testers. Google requires at least 12 users over a two-week testing period before allowing production access. Interestingly, it’s apparently pretty common to get denied production access even after you have 12 users, the minimum stated. It’s probably some secret requirement about app use frequency, although they didn’t say that. The reason for rejection was uninformative. Once denied, you then have a mandatory 14 day wait period before you can apply again. I did some research and found that it’s probably because they want a lot of active use in that time frame. Instead of chasing other testers (people who would test for the sake of testing but not be people with EPI), I waited the 14 days and applied again and made it clear that people wouldn’t be using the app every day, and otherwise left my answers the same…and this time lucked into approval. This meant I was allowed to submit for review for production access to the Play Store. I submitted….and was rejected, because there are rules that medical and medical education apps can only be distributed by developers tied to organizations that have a business number and have been approved. What?!

Apparently Google has a policy that medical “education” apps must be distributed by organizations with approved business credentials. The screenshots sent back to me seem to be flagging on the button I had on the home screen that described PERT and dosing PERT and information about the app. I am an individual (not an organization or a nonprofit or a company) and I’m making this app available for free to help people, so I didn’t want to have to go chase a nonprofit who might have android developer credentials to tie my app to.

What I tried next was removing the button with the ‘education’ info, changing the tags on my app to fall under health & fitness rather than ‘medical’, and resubmitting. No other changes.

This time…it was accepted!

Phew.

–

iOS or Android: which was easier? A newbie's perspective on iOS and Android development and app deployment, a blog by Dana M. Lewis from DIYPS.org TL;DR: as more and more people are going to vibe code their way to having Android and/or iOS apps, it’s very feasible for people with less experience to do both and to distribute apps on both platforms (iOS App Store and Google Play Store for Android). However, there’s an up front higher cost to iOS ($99/year) but a slightly easier, more intuitive experience for deploying your apps and getting them reviewed and approved. Conversely, Android development, despite its lower entry cost ($25 once), involves navigating a more complicated development environment, less intuitive deployment processes, and opaque requirements for app approval. You pay with your time, but if you plan to eventually build multiple apps, once you figure it out you can repeat the process more easily. Both are viable paths for app distribution if you’re building iOS and Android apps in the LLM-era of assisted coding, but don’t be surprised if you hit bumps in the road for deploying for testing or production.

Which should you choose for your first app, iOS or Android? It depends on if you have a fondness for either iOS or Android ecosystem; if one is closer to development languages you already know; or if one is easier to integrate/work with your LLM of choice. (I now have both working with Cursor and both also can be pulled into the ChatGPT app). Cost may be an issue, if $99/year is out of reach as a recurring cost, but keep in mind you’ll pay with your time for Android development even though it’s a $25 single time user account setup fee for developers. You also may want to think about whether your first app is a one-off or if you think you might do more apps in the future, which may change the context for paying the Apple developer fee yearly. Given the requirements to test with a certain number of users for Play Store access, it’s easier to go from testing to production/store publication on Apple than it is for Google, which might factor into subsequent app and platform decisions, too.

	iOS	Android
Creating a developer account	better	(takes more time, ID verification), one time $25 fee, requires physical device access
Fees/costs	$99/year	Better: one time $25 fee for account creation
IDE	better	(more challenging with different languages/files and requires gradle syncing)
Physical device access required	No (unless you need to test integrations like HealthKit or audio input or exporting files or sending emails)	Yes, as part of the account setup but you could borrow someone’s phone to accomplish this
Getting your app to the web for testing	Pretty clear once you realize you have to “archive” your app from XCode, pops up a window that then guides you through sending to TestFlight. (Whether or not you actually test in TestFlight, you can then add to submit for review). Hiccups occasionally if Apple requires you to sign new agreements in the web interface (watch for email notifications and if you get errors about your account not being correct, if you haven’t changed which account you are logged into with XCode, check the Apple developer account page on the web. Accept agreements, try again to archive in XCode, and it should clear that error and proceed.	A little more complicated with generating signed bundles, finding where that file was saved on your computer, then dragging and dropping or attaching it and submitting for testing. Also more challenging to manage adding testers and facilitate access to test.
Submitting for approval/production access	Better, easy to see what stage of review your app is in.	Challenging to navigate where/how to do this in web interface the first time, and Google has obtuse, unstated requirements about app usage during testing. Expect to be rejected the first time (or more) and have to wait 14 days to resubmit.
Distribution once live on the store	Same	Same

Just Do Something (Permission Granted)

March 7, 2025April 12, 2025 by Dana Lewis

Just do it. And by it, I mean anything. You don’t need permission, but if you want permission, you have it.

If you’ve ever found yourself feeling stuck, overwhelmed (by uncertainty or the status of the world), and not sure what to do, I’ll tell you what to do.

Do something, no matter how small. Just don’t wait, go do it now.

Let’s imagine you have a grand vision for a project, but it’s something you feel like you need funding for, or partners for, or other people to work on, or any number of things that leave you feeling frozen and unable to do anything to get started. Or it’s something you want the world to have but it’s something that requires expertise to build or do, and you don’t have that expertise.

The reality is…you don’t need those things to get started.

You can get started RIGHT NOW.

The trick is to start small. As small as opening up a document and writing one sentence. But first, tell yourself, “I am not going to write an entire plan for Z”. Nope, you’re not going to do that. But what you are going to do is open the document and write down what the document is for. “This document is where I will keep notes about Plan Z”. If you have some ideas so far, write them down. Don’t make them pretty! Typos are great. You can even use voice dictation and verbalize your notes. For example “develop overall strategy, prompt an LLM for an outline of steps, write an email to person A about their interest in project Z”.

Thanks to advances in technology, you now have a helper to get started or tackle the next step, no matter how big or small. You can come back later and say “I’m not going to do all of this, but I am going to write the prompt for my LLM to create an outline of steps to develop the strategy for project Z”. That’s all you have to do: write the prompt. But you may find yourself wanting to go ahead and paste the prompt and hit run on the LLM. You don’t have to read the output yet, but it’s there for next time. Then next time, you can copy and paste the output into your doc and review it. Maybe there will be some steps you feel like taking then, or maybe you generate follow up prompts. Maybe your next step is to ask the LLM to write an email to person A about the project Z, based on the outline it generated. (Some other tips for prompting and getting started with LLMs here, if you want them.)

The beauty of starting small is that once you have something, anything, then you are making forward progress! You need progress to make a snowball, not just a snowflake in the air. Everything you do adds to the snowball. And the more you do, the easier it will get because you will have practice breaking things down into the smallest possible next step. Every time you find yourself procrastinating or saying “I can’t do thing B”, get in the habit of catching yourself and saying: 1) what could I do next? And write that down, even if you don’t do it then, and 2) ask an LLM “is it possible” or “how might I do thing B?” and break it down further and further until there’s steps you think you could take, even if you don’t take them then.

I’ve seen posts suggesting that increasingly funders (such as VCs, but I imagine it applies to other types of funders too) are going to be less likely to take projects seriously that don’t have a working prototype or an MVP or something in the works. It’s now easier than ever to build things, thanks to LLMs, and that means it’s easier for YOU to build things, too.

Yes, you. Even if you’re “not technical”, even if you “don’t know how to code”, or even if you’re “not a computer person”. Your excuses are gone. If you don’t do it, it’s because you don’t WANT to do it. Not knowing how to do it is no longer valid. Sure, maybe you don’t have time or don’t want to prioritize it – fine. But if it’s important to you to get other people involved (with funding or applications for funding or recruiting developers), then you should invest some of your time first and do something, anything, to get it started and figure out how to get things going. It doesn’t have to be perfect, it just has to be started. The more progress you make, the easier it is to share and the more people can discover your vision and jump on board with helping you move faster.

Another trigger you can watch for is finding yourself thinking or saying “I wish someone would do Y” or “I wish someone would make Z”. Stop and ask yourself “what would it take to build Y or Z?” and consider prompting an LLM to lay out what it would take. You might decide not to do it, but information is power, and you can make a more informed decision about whether this is something that’s important enough for you to prioritize doing.

And maybe you don’t have an idea for a project yet, but if you’re stewing with uncertainty these days, you can still make an impact by taking action, no matter how small. Remember, small adds up. Doing something for someone else is better than anything you could do for yourself, and I can say from experience it feels really good to make even small actions, whether it’s at the global level or down to the neighborhood level.

You probably know more what your local community needs, but to start you brainstorming, things you can do include:

Go sign up for a session to volunteer at a local food bank
Take groceries to the local food bank
Ask the local food bank if they have specific needs related to allergies etc, such as whether they need donations of gluten-free food for people with celiac
Go take books and deposit them at the free little libraries around your neighborhood
Sign up for a shift or get involved at a community garden
Paint rocks and go put them out along your local walking trails for people to discover
Write a social media post about your favorite charity and why you support it, and post it online or email it to your friends
Do a cost-effective analysis for your favorite nonprofit and share it with them (you may need some data from them first) and also post it publicly

Just-do-something-you-have-permission-DanaMLewis I’ve learned from experience that waiting rarely creates better outcomes. It only delays impact.

Progress doesn’t require permission: it requires action.

What are you waiting for? Go do something.

Scale yourself

March 3, 2025April 12, 2025 by Dana Lewis

One of the things I wish people would consider more often when thinking about AI is how they can use it to scale themselves. What are some time-consuming things that they currently have to do themselves that AI could do for them to streamline their output and increase their productivity? Productivity for giving them more time to do the things only they can do, the things they want to do, or the things they love to do. (And to help stop procrastinating on things they have to do.)

I have a habit of trying to scale myself. These days, it’s often related to EPI (exocrine pancreatic insufficiency, which some areas of the world know by the acronym PEI). I developed a strong knowledge base first from personal experience, then by doing research – including a systematic review where I read hundreds, plural, of research papers on key topics related to design protocols and guidelines. As a result of both personal and research experience, I have a lot of knowledge. It gets tapped almost daily in the EPI support groups that I’m a part of.

Whenever I notice myself answering the same question repeatedly, I make a mental note of it. Eventually, if a topic comes up often enough, I turn my response into a blog post. This way, I can provide a well-structured, comprehensive answer with more time and context than a quick comment on social media allows – and with the ability to give the same, high quality answer to multiple people (and in some cases, hundreds or thousands of people rather than the few who might see the comment buried in a response thread).

A few examples of this include:

Explaining why fecal elastase test results change over time; why they’re not perfect; what being above or below certain cutoffs mean; why you don’t need to stop taking enzymes for an elastase test; why elastase test isn’t directly impacted by taking enzymes; why elastase isn’t used to determine how much enzymes you need or whether or not enzymes are ‘working for you’. All that in one post (here) with a lot of context and resources including links to medical literature to back all that up, which is hard to do well as one-off facebook comments and easier to do in a blog post format.
A guide to discussing enzyme dosing starting guidelines and best practices for titrating (increasing) your enzyme dose, including resources (again, medical literature) to share with your doctor to help inform your discussions
Information on an approach to record what you’re eating, and why, in order to adjust and optimize your enzyme dosing, because enzymes have to (should) be dosed in relationship to the food consumed.

One of my favorite things with this approach is then seeing other people begin to share the links to my longer-form content to help answer common questions. By writing things down in a shareable way, it also enables and supports other people to scale your work by sharing it easily. This has started to happen more and more with the elastase blog post, in part because there are so few resources that cover this information all in one place.

For me, I lean toward writing, but for other people that could be videos, podcast/audio recording, or other formats that can capture things you know and make them shareable, thus scaling yourself.

For me, this approach of “scaling myself” and thinking about longer form content to post online instead of re-typing similar answers over and over again isn’t unique to EPI.

I have been doing this for over a decade. I developed this pattern early after we developed and shared OpenAPS (the first open source automated insulin delivery algorithm) with the world. Early on, I found myself answering the same technical questions repeatedly in online discussions with the same answers. Typing out explanations on my phone was inefficient, and if one person had a question, others likely had the same one. Instead of repeating myself, I took the time to document answers. I would often pause, write up the information in the documentation, and share that instead. This made it easier and quicker to go find and share a link instead of retyping responses, and it also took less time, so I was willing to do it more quickly than if I had to delay what I was doing in real life in order to type out a long yet already-answered question. Over time, I had to do less one-off typing on my phone (and could save that time and energy for true, one-off unique questions) and could share links with a lot more information more easily.

How do I use AI to scale this type of work?

A lot of the above tasks are related to writing. There are different ways you can use AI for writing, without having it write something completely. You can give it notes – whether you type or voice dictate them – and have it clean up your notes, so you can focus on thinking and not about typing or fixing typos that break your flow. You can have it convert the notes into full sentences. You can ask it to write a paragraph or an article based on the notes. You can ask it to suggest wording for a particular sentence you want to clarify for your audience.

If you think about the AI as an intern and/or a partner/collaborator who you would ask to review or edit for you, you’ll likely find even more ways to integrate AI into different parts of your writing process, even if it’s not doing the full writing for you.

I have also tried to task the AI with writing for me, with mixed results. This doesn’t mean I don’t use it, but I’ve been practicing and learning where it generates usable content and where it doesn’t.

A lot of it depends on the prompt and the topic (as much as it does the output in terms of style, length, intended audience etc).

If it’s a topic that’s “known”, it can write more content that I can take and edit and transform, as opposed to when I am trying to write about a concept that is far from the current knowledge base. (I mean far for both humans and of AI – a lot of my work is bleeding edge, pushing fields towards new developments and leading humans there.) Sometimes I ask it to write something and end up using none of the content, but by saying “ugh no” my brain has jumped to saying to myself “it should really say…” and I am able to more quickly springboard into manually writing the content I was previously slow on. In other words, it can be a brainstorming tool in the opposite sense, showing me what I do not want to say on a topic! And on some of my frontier/bleeding edge topics, it reflects what is commonly ‘known’ and when what is known is now wrong (example, as always, of how it’s commonly incorrectly reported that chronic pancreatitis is the most common cause of EPI), it helps me more clearly distinguish the new content from the old, wrong, or misinformed.

(Also, it’s worth reminding you what I have to remind myself, that AI is changing constantly and new tools override what is known about what tasks do and don’t do well! For example, in between writing this and posting it, OpenAI released GPT4.5, which is reportedly better at writing-related tasks than GPT-4o and other older models. I’ll have to test it and see if that’s true and for what kinds of writing tasks!)

This isn’t the only way you can scale yourself with AI, though. Scaling yourself doesn’t have to be limited to writing and documentation style tasks. AI and other tools can help with many tasks (more examples here and here), such as:

Cleaning and transforming data into different formats
Converting a CSV file into a more readable table
Writing code to automate tedious data processing
Drafting plain-language instructions for engineers or programmers
Checking whether instructions or explanations are clear and understandable, and identifying any gaps in logic that you missed on your first pass

By leveraging AI and other automation tools, you can free up time and energy for higher-value work: the things you are uniquely suited to do in the world, and the things that you want or love to do. And do them more easily!

Pro tip: if you find yourself procrastinating a task, this may be a good sign that you could use AI for some of it.

I’m trying to use noticing procrastination as a trigger for considering AI for a task.

An example of this is an upcoming post with a bunch of math and meaty cost analysis that I originally did by hand. I needed (wanted) to re-do these estimates with different numbers, but procrastinated a bit because having to carefully re-do all the estimates and replace them throughout the blog post seemed tedious, so my brain wanted to procrastinate. So, I took the blog post and dumped it in with a prompt asking it to write Jupyter Notebook code to replicate the analyses explained via the plain language post, with the ability to adjust all input variables and see the results in a table so I could compare the original and updated numbers. It took less than 1 minute to generate this code and about 5 minutes for me to copy/paste, update the numbers, run it, and evaluate the output and decide what to update in the post. Manually, this would’ve taken 30-60 minutes due to needing to check my work manually and trace it throughout the post. Instead, this automated the tedious bit and will result in this new post coming out next week rather than weeks from now (read about it here – it’s an analysis on how cost-effect Life for a Child is, a charity supporting people living with diabetes in low- and middle-income countries that can use your help to save lives.)

I encourage you to think about scaling yourself and identifying a task or series of tasks where you can get in the habit of leveraging these tools to do so. Like most things, the first time or two might take a little more time. But once you figure out what tasks or projects are suited for this, the time savings escalate. Just like learning how to use any new software, tool, or approach. A little bit of invested time up front will likely save you a lot of time in the future.

DIYPS.org

#WeAreNotWaiting to make the world a better place

large language model

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

AI is often an accessibility tool, even if you don’t use it that way

The data we leave behind in clinical trials and why it matters for clinical care and healthcare research in the future with AI

Try, Try Again with AI

iOS and Android development experience for newbies

Just Do Something (Permission Granted)

Scale yourself

Recent Posts

Recent Comments

Archives

Categories

Meta