Fall Detection to Care Navigation
Aging services organizations get pitched more AI than almost any other part of the nonprofit sector, because the demographics are irresistible to vendors and the buyers are often small agencies with no technical staff. The technology categories are genuinely different from one another, the evidence behind them varies from strong to nonexistent, and the question that determines whether a deployment succeeds is almost never about the technology. It is about who answers when the system says something is wrong.
A typical Area Agency on Aging runs congregate and home-delivered meals, information and assistance, benefits counseling, caregiver support, and a set of contracted in-home services, on a budget that has not grown as fast as the population it serves. Senior centers, meal programs, and community-based aging organizations operate on similar terms. Everyone in this field is being asked to serve more people with roughly the same staff, which is exactly the pressure that makes technology pitches land.
The pitches themselves are increasingly sophisticated and increasingly hard to evaluate. Ambient sensors that detect falls without a wearable. Conversational devices that check in daily and reduce isolation. Systems that screen a client for benefits they are not receiving. Software that routes meal delivery drivers more efficiently. These are four separate products solving four separate problems, and treating them as one category called AI for seniors is how organizations end up buying the impressive thing rather than the useful one.
There is also a structural problem specific to this field. Much of the reimbursement for care technology flows through clinical channels, meaning a physician practice or home health agency billing for remote patient monitoring, while the organizations closest to the older adult are community-based nonprofits that cannot bill for any of it. That mismatch shapes what is affordable, and it explains why so many aging services organizations end up piloting technology on grant money that runs out before the program becomes part of anything.
This article works through the four categories, what the available evidence actually supports in each, the operational question that determines whether a deployment helps or creates liability, the consent problems that arise when clients have cognitive impairment and adult children with strong opinions, and a procurement approach for an organization with no IT department. For a broader view of the field, our overview of AI for senior services nonprofits covers the wider landscape.
Four Categories, Not One Market
The single most useful thing an aging services organization can do before evaluating anything is to sort the offers into categories, because the questions you should ask differ completely between them. A monitoring system needs a response plan. A companionship device needs a plan for what happens when the client stops engaging. A navigation tool needs a verification step. An operations tool needs almost nothing beyond a decent trial period, which is why it is usually the right place to start.
Monitoring and safety technology detects events or changes in the home. That includes wearable fall detection, ambient sensors that infer a fall from motion or floor pressure, and passive activity monitoring that flags deviations from routine such as a refrigerator that has not been opened. This is the category with the highest stakes, the most vendor enthusiasm, and the most operational burden, because every alert generated has to go somewhere.
Companionship and check-in technology has conversation as its core function. Proactive devices that initiate contact, voice assistants configured for older adults, and automated wellness calls all sit here. The intent is reducing social isolation and providing daily contact that staff cannot deliver at scale. This category attracts the most skepticism from staff and, in the programs where it has been studied at scale, has produced some of the more encouraging reported results.
Care navigation and benefits work is about complexity rather than presence. Older adults are frequently eligible for programs they are not enrolled in, and the reasons are almost always about the difficulty of the process rather than about eligibility itself. Tools that help staff or clients work through eligibility, prepare applications, and understand notices address a large and well-documented gap, and they are considerably cheaper than hardware.
Operations is the fourth category and the one nobody puts in a press release. Route optimization for home-delivered meals, volunteer scheduling, transportation dispatch, intake documentation, and the reporting that funders require. The impact is real, the risk is low, and the savings often fund the more interesting projects.
Monitoring and safety
Highest stakes, heaviest operational load
Fall detection, activity pattern monitoring, environmental sensors. Generates alerts that require a defined human response. Do not deploy without answering the response question first.
Companionship and check-in
Addresses isolation, not clinical need
Proactive conversational devices and automated wellness contact. Best reported results come from multi-year state programs with careful screening rather than open enrollment.
Care navigation and benefits
Cheapest category with the clearest payoff
Eligibility screening, application preparation, plain-language explanation of notices. Software rather than hardware, and it augments the counselors you already employ.
Operations
Unglamorous, reliable, start here
Meal route optimization, volunteer and driver scheduling, transportation dispatch, intake and reporting. Low risk, measurable savings, and no consent complications.
Every Deployment Turns on One Question: Who Answers the Alert?
A monitoring system does not provide safety. It provides information, and information only becomes safety when a person acts on it within a useful window. This sounds obvious and it is routinely skipped, because the vendor demonstration ends at the alert and the organization assumes the rest will sort itself out. It does not sort itself out, and the gap between detection and response is where deployments fail.
Work through the specifics before signing anything. When a fall alert fires at two in the morning, who receives it? Is that a staff member, an answering service, a family contact, or a monitoring center the vendor operates? If it is your staff, are they on call, are they paid to be on call, and what is the expected response? If nobody answers, what happens next and after how long? If the answer to any of these is unclear, the organization has purchased a system that will eventually generate an alert nobody handles, and the consequences of that fall on you rather than on the vendor.
The most common workable arrangement for a community-based organization is not to own the response at all. The vendor operates a monitoring center, the client's emergency contacts are configured directly, and the nonprofit's role is enrollment, training, troubleshooting, and periodic check-ins that the alerts help prioritize. That is a modest role and it is honest about capacity. Organizations that instead position themselves as the responder are taking on a twenty-four-hour obligation that a program with three staff cannot sustain, and the obligation does not disappear on weekends.
There is a related and gentler version of this for non-emergency monitoring. Activity pattern systems that flag a change in routine are not emergencies and should not be treated as such. The right response is a phone call from a care coordinator during business hours, and the value is that the call is targeted rather than random. Framed that way, passive monitoring becomes a prioritization tool for a caseload rather than an alarm system, which is both more achievable and more useful.
Detection without response is worse than nothing
A client who believes someone is watching may take risks they otherwise would not, and a family that believes a system is monitoring may check in less often. If the response side is weak, the technology can reduce actual safety while increasing the feeling of it.
Write the response protocol before the procurement, not after. If you cannot staff the protocol you have written, that is the answer to whether you should deploy.
Fall Detection Is a Response System With a Sensor Attached
Falls are the dominant safety concern in aging services for good reason, and the long-standing intervention has been the wearable button. The problem with buttons is well known to anyone who has run one of these programs: people do not wear them. They are stigmatizing, uncomfortable, forgotten on the nightstand, and taken off in the shower, which is where a substantial share of falls happen. Automatic detection was supposed to solve the pressing problem, and it does, but only for the people still wearing the device.
That is what makes ambient detection interesting. Systems using radar, floor sensors, or camera-free depth sensing detect falls without requiring the client to wear or do anything, which eliminates the compliance problem entirely. They also cost more, require installation, work only in the rooms they cover, and introduce a surveillance question that a wearable does not, because the client cannot take the room off. Whether that tradeoff is right depends heavily on the individual, which argues for offering both rather than standardizing on one.
False alarms deserve more attention than they usually get in procurement. Every detection system trades sensitivity against specificity, and the setting that catches every real fall will also fire when someone sits down heavily or drops a bag. In a program with fifty clients, a false alarm rate that sounds small in a specification becomes several unnecessary alerts a week, and the practical result is alert fatigue among whoever is responding. Ask vendors directly for real-world false positive rates from deployments of similar size and be skeptical of answers expressed only as accuracy percentages, because accuracy on a rare event is a misleading number.
The reimbursement structure is the constraint most organizations hit last and should consider first. Remote monitoring is billable in the healthcare system by clinical providers under established Medicare codes, but a senior center or Area Agency on Aging is generally not a billing provider, so the same device that generates revenue for a home health agency is a pure cost for you. Some organizations resolve this by partnering with a clinical entity that bills and shares infrastructure, some fund it through Older Americans Act dollars or state aging appropriations, and some conclude that hardware is not their business. All three are defensible; assuming the money will appear is not.
What to ask a fall detection vendor
Beyond the demonstration
- What is the real-world false alarm rate per device per month in a deployment like ours?
- What proportion of enrolled clients are still using the device at six months and at twelve?
- Who staffs the monitoring center, what are their hours, and what is the median time to human contact?
- What happens during a power outage, an internet outage, and a cellular outage?
- What data leaves the home, where is it stored, who can access it, and what happens to it at termination?
- If we end the contract, do the devices keep working, and who pays to remove installed hardware?
Companion Technology and the Evidence We Actually Have
Conversational companion devices provoke stronger reactions than anything else in this space. Staff often find the idea troubling, on the reasonable grounds that a machine talking to a lonely person is a poor substitute for human contact and that offering one can look like giving up on the harder work. That objection deserves to be taken seriously rather than dismissed, and it should be weighed against the fact that the alternative on offer is frequently not human contact but nothing at all.
The most substantial public evidence comes from a state government rather than a vendor. The New York State Office for the Aging has run a multi-year deployment of a proactive companion device distributed through county Area Agencies on Aging, and has published participant-reported results across several program years indicating large majorities reporting reduced loneliness and improved overall wellbeing, along with very high daily interaction rates. This is unusually good documentation for the category, and it comes from a public agency reporting on its own program rather than from marketing material.
It is still worth reading carefully. These are participant-reported outcomes rather than a controlled comparison, and the participants were screened and selected by county agencies rather than randomly assigned, which means the people who received devices were the people whom experienced staff judged likely to benefit. That selection is a feature of how a real program should work and a limitation on what the numbers prove. The honest summary is that a carefully screened deployment with real support produced strong self-reported results, and that this says little about what would happen if the same device were handed out broadly.
Cost is the other practical consideration. Subscriptions for devices in this category have generally run in the hundreds of dollars per client per year, which is manageable for a screened cohort and completely unmanageable across a full service population. This forces exactly the screening discipline that appears to make the programs work, so it is less of a problem than it first appears, but it does mean the program is a targeted intervention rather than a general offering.
Two boundaries should be stated plainly in any program of this kind. A companion device is not a clinical intervention and should not be positioned as treatment for depression or any other health condition. And anything touching a health or safety emergency belongs to trained humans and established response systems, not to a conversational device, whatever the marketing suggests. Keeping the technology on the social contact side of that line is what makes it defensible. Our discussion of designing automated services that do not feel automated explores the broader question of where automation belongs in direct service.
Where it appears to work
Screened clients who live alone, have limited daily contact, retain the cognitive capacity to converse, and consent enthusiastically rather than under family pressure. Support during the first weeks matters as much as the device.
Where it does not
Broad distribution without screening, clients with significant cognitive impairment who find it confusing or distressing, and any situation where the device is being used to justify reducing human visits.
Care Navigation Is the Quietest and Best Opportunity
Benefits under-enrollment among older adults is one of the most persistent problems in the field and one of the least technologically glamorous. Large numbers of eligible people are not receiving nutrition assistance, Medicare Savings Program help with premiums, prescription drug subsidies, energy assistance, or property tax relief they qualify for. The barriers are almost never eligibility. They are the length of the application, the documentation required, the interaction between programs, and the difficulty of understanding a notice written for administrators.
This is a language and complexity problem, which is precisely what current AI is good at. A benefits counselor working through a client's situation can use a model to draft a plain-language explanation of what a denial notice means, to enumerate which programs a given set of circumstances might reach, to prepare a document checklist specific to the client, and to draft an appeal letter. Each of these is a task that takes a skilled counselor real time and that a model can produce a solid first version of in seconds.
The essential discipline is that eligibility rules vary by state, change annually, and are frequently what models get wrong. A general-purpose assistant asked whether someone qualifies for a program will produce a confident answer drawn from an unknown vintage of an unknown state's rules. That answer must never reach a client unverified. The workable pattern is to use the model for explanation, structuring, and drafting, while the actual eligibility determination comes from the current official source and the counselor's own knowledge. Framed that way, the tool speeds up the work without becoming the authority on it.
A second discipline concerns what goes into the tool. Client names, Social Security numbers, Medicare numbers, and financial details should not be typed into a consumer assistant. Counselors can work with anonymized descriptions of a situation and apply the result to the actual case themselves, which loses almost nothing and avoids a serious exposure. If your organization handles protected health information, the same considerations that govern your other systems apply here, and our guide to HIPAA-compliant databases for health-focused nonprofits covers the underlying requirements.
The reason this category is worth prioritizing is that the benefit is direct, measurable, and financial. An additional successful Medicare Savings Program enrollment is worth a meaningful monthly amount to a client on a fixed income, and enrollments are already counted in most agencies' reporting. That makes it an unusually easy program to justify to a board and to a funder, and it requires no hardware, no installation, and no overnight response protocol.
A safe division of labor for benefits work
The model drafts, the counselor decides
- Explaining a notice or a program in plain language at a reading level the client can use.
- Producing a client-specific document checklist so the appointment is not wasted on missing paperwork.
- Drafting appeal letters and cover explanations that the counselor reviews and signs.
- Translating written materials into the languages your clients read, with a fluent human review.
- Never: making the eligibility determination, or receiving identifying client information.
The Back Office Is Where the Money Actually Is
Home-delivered meals programs are logistics operations that happen to serve food, and most of them are routed by a coordinator with local knowledge and a printed list. That coordinator is usually very good, and they are also a single point of failure, spending several hours a week on a problem that routing software solves in seconds while accounting for volunteer availability, vehicle capacity, and delivery windows. The savings are not theoretical, and the freed time goes back into client contact.
Volunteer coordination is the second reliable win. Aging services organizations run on volunteers, and matching availability to routes, handling last-minute cancellations, and keeping people engaged is administrative work that consumes a coordinator's week. Automated scheduling with intelligent substitution suggestions, plus drafted communications that a human sends, reduces that load substantially. Our guide to streamlining volunteer onboarding and training with AI covers the front end of that pipeline.
Documentation and reporting is the third. Aging services organizations report into state units on aging under detailed requirements, and the assessment and reassessment instruments used in this field are long. Assistance with drafting case notes from a conversation, with checking a record for missing required elements before submission, and with assembling recurring reports from data the organization already holds saves time that currently comes out of direct service. The same caution about client identifiers applies, which usually means using a tool covered by the appropriate agreements rather than a consumer product.
Transportation is the fourth and often the most constrained service an agency offers. Demand-response scheduling, where a client calls for a ride and a dispatcher fits it into a route, is a genuinely hard optimization problem that agencies solve by hand and imperfectly. Improvement here directly increases the number of rides delivered with the same vehicles and drivers, which is the sort of capacity gain that no amount of program redesign produces.
The argument for starting in this category is not that it is exciting. It is that it carries almost no consent complexity, produces savings you can point at within a quarter, builds staff confidence with the technology before anything touches a client, and generates the operating room that a more ambitious pilot requires.
Consent, Capacity, and the Surveillance Question
Every other field of nonprofit work can treat consent as a form. Aging services cannot, because a meaningful share of clients have cognitive impairment that fluctuates, because family members frequently have strong opinions and sometimes legal authority, and because the technology under discussion observes people continuously in their own homes. This is the part of the subject that most deserves careful thought and receives the least.
Start from the position that the client consents unless there is a legal reason they cannot. Capacity is decision-specific and fluctuating, and a person who cannot manage their finances may be entirely capable of deciding whether they want a sensor in their bedroom. Where a family member holds authority, the client's preference still matters and should be recorded even when it does not control the outcome. Where a family member is pressing for monitoring that the client resists, the organization should recognize that it is being asked to mediate a family disagreement, not to install a device, and should behave accordingly.
Be explicit about who sees what. Adult children asking for a dashboard showing a parent's daily activity are asking for surveillance of an adult, however loving the motivation. A client who agreed to fall detection has not necessarily agreed to their daughter seeing what time they got up. Separating the safety function from the visibility function, and letting the client decide about each independently, resolves most of these situations before they become conflicts. Where a client declines family visibility, that decision should be honored and documented.
Make declining easy and make it real. Consent obtained from someone who believes their meals or their services depend on agreeing is not consent, and the power imbalance in this relationship is substantial. State clearly that participation is optional and unrelated to other services, offer a genuine way to stop, and check in after a few months rather than treating the initial signature as permanent. People change their minds about being observed, particularly once they have experienced it.
Finally, be honest internally about what the technology is for. There is a version of every deployment in this field that is primarily about reducing organizational risk or reassuring families, and a version that is primarily about the client's own safety and independence. Those often point to the same purchase, but they point to different configurations, different defaults, and different answers when the client objects. Knowing which one you are actually doing is the difference between a program that respects the people it serves and one that merely appears to.
Questions to settle before the first device goes in
- Who consents when capacity is uncertain, and how is the client's own preference recorded regardless?
- Which family members see which data, and can the client change that decision later?
- What does the client have to do to stop, and how quickly does it actually stop?
- What is recorded in the home, is any audio or video retained, and for how long?
- Would we be comfortable explaining this arrangement to the client's neighbor in plain language?
Buying Well Without an IT Department
Aging services organizations are attractive customers to vendors and poorly equipped to evaluate them. The typical agency has no technical staff, a director who is already overcommitted, and a board that is enthusiastic about innovation in the abstract. That combination produces purchases driven by demonstrations, which favor the most polished vendor rather than the most suitable one.
The most effective correction is also the cheapest: talk to three current customers of similar size before deciding, and ask them what went wrong rather than whether they are satisfied. Vendors will provide references, and references will be positive, but the question about what surprised them and what they would do differently produces useful answers even from happy customers. A vendor unwilling to connect you with comparable organizations is telling you something about their deployment history.
Design the pilot to be able to fail. That means a defined and short duration, a small cohort, a written statement of what result would justify continuing, and an exit that does not leave you with stranded hardware or a data extraction problem. Most failed technology deployments in this sector were never formally decided upon; they simply continued because stopping would have been an admission. A pilot with a stated success threshold and an end date avoids that trap entirely.
Ask about the vendor's own durability. This is a market with substantial venture funding and frequent consolidation, and a device that stops receiving support becomes an expensive object in someone's living room. Reasonable questions include how long the company has been operating, how many clients are currently deployed, what happens to devices if the company is acquired, and whether the data is exportable in a usable form. Our nonprofit AI vendor evaluation checklist covers the general version of these questions in more detail.
Finally, budget for the human side, which is where these programs actually consume resources. Enrollment visits, initial training for clients who may need several sessions, troubleshooting calls, battery and connectivity problems, and the periodic check-in that keeps engagement from decaying. A rough planning assumption is that ongoing staff support costs at least as much as the subscription, and organizations that budget only for the technology find the program quietly starved. Organizations serving similar populations in a clinical setting face a comparable pattern, and our look at AI in community health centers covers that adjacent experience.
A pilot design that protects you
Six elements, all agreed in writing before launch
- A fixed end date, typically ninety to one hundred eighty days, with no automatic renewal.
- A cohort small enough that you can call every participant yourself at the end.
- A written success threshold agreed before launch, including a continued-use rate.
- A named staff owner with allocated hours, not an addition to someone's existing full week.
- A data export and deletion commitment in the contract, effective at termination for any reason.
- An agreed plan for removing hardware and closing out clients if you do not continue.
Conclusion
The technology being sold to aging services organizations is not one thing, and the most consequential decision an agency makes is which category it enters first. Monitoring carries the highest stakes and the heaviest operational obligation, and it should not be attempted until the response question has a real answer with real staffing behind it. Companion technology has better documented results than skeptics expect, from screened programs with genuine support, and worse results than vendors imply when distributed broadly. Care navigation is cheap, effective, and underused. Operations is where a cautious organization should start.
Across all four, the constraint is rarely the model or the sensor. It is whether the organization has staff time for enrollment and support, a clear position on who consents and who sees the data, a budget that survives the pilot grant, and the willingness to stop a deployment that is not working. Those are management questions, and they are the ones that separate agencies with useful technology from agencies with a closet of returned devices.
It is worth holding onto the dignity question throughout, because it is easy to lose in a procurement process. The people in these programs are adults who have run households, held jobs, and made their own decisions for seventy or eighty years. Technology that helps them stay independent is a gift. Technology that watches them for the reassurance of others, or that substitutes for contact they would rather have from a person, is something else, and the difference is usually visible in how the organization behaves when a client says no.
If you are choosing where to begin, route your meal deliveries better and use AI to get more of your clients enrolled in the benefits they already qualify for. Neither will impress anyone at a conference. Both will produce a result you can point to within a quarter, and both will teach your staff enough to evaluate the next pitch with more confidence than the last one.
Evaluating Technology for Your Aging Services Programs?
We help aging services organizations sort the pitches from the possibilities, design pilots that can honestly fail, and build the operational plan that makes a deployment work.