A practical framework for governing technology in senior living — before it governs you.
Technology is quietly taking over decisions in senior living that used to belong to people. A sensor decides whether a resident’s movement warrants an alert. A predictive model decides whether a resident is high-risk or low-risk for deterioration. A documentation system shapes what language enters the chart. A scheduling tool influences how often someone is rounded on. None of this is inherently bad, and much of it is genuinely useful. But each of these tools has slipped into a place in the workflow where it shapes a clinical or operational judgment — and the moment a tool shapes a judgment, it raises a question the technology itself can never answer: when this goes wrong, who is accountable?
The answer, every time, is the operator. Not the vendor. Not the algorithm. The licensed, regulated, accountable operator whose name is on the door and, eventually, on the caption. That single fact should govern how leaders approach every piece of technology they bring into a community. It rarely does, because most organizations are still asking the wrong question. They ask whether the technology works. The better question is what happens when it doesn’t — and who answers for it.
Four Questions That Outlast Every Tool
Because the technology will keep changing, the framework for examining it has to be independent of the technology. I use four questions, and their power is precisely that they do not care what the tool is. They apply unchanged to a sensor, a predictive model, a documentation system, or a platform that has not been invented yet.
Outcome. What actually failed, and what harm or near miss followed? Start with the resident, not the tool. The technology is the last thing to examine, not the first — a discipline that keeps the analysis honest and keeps the organization from defending a product instead of caring for a person.
Decision. Who relied on the output, the alert, or the absence of an alert? If the honest answer is “the tool decided,” the problem is already located. Technology can inform a decision. It cannot be the decision-maker, because it cannot hold the duty. Accountability does not transfer to something that cannot be held to account.
Control. What should have existed before the tool went live — training, validation, an override point, an escalation path? And was that control real or merely theoretical? The most common finding in any technology failure is a safeguard that existed on paper and never in practice: an override no one was trained to use, an escalation trigger no one had defined.
Response. What would the organization need to say tomorrow to the family, to counsel, to its insurer, to the board, and to a regulator? Those are five audiences with five different needs, and the instinct to produce one statement for all of them is where good organizations get into trouble. The response also includes preservation — the logs, the data, the vendor communications — which most operators have no process to secure when the tool belongs to a third party.
Tools change. These four questions don’t. That is the entire point. Next year the technology will be different and the brochures will use different words, but the questions will be identical — and an organization that has internalized them is ready for tools that do not yet exist.
The Courts Are Already Drawing the Line
This is not a forecast. The first wave of technology-in-healthcare cases is now past the motion-to-dismiss stage, which means discovery, depositions, and a factual record that the next wave will build on. A few of these cases are clarifying because they show exactly where accountability lands.
In litigation over a major insurer’s predictive tool used to manage post-acute care, the named defendant is the operator — not the vendor that built the model, and certainly not the model itself. The tool is a witness. The duty stayed home. In a separate matter involving an algorithmic claim-review system, a federal court found that a physician spending roughly a second to confirm an automated denial is not performing a review at all; approval, by itself, is not judgment. And in a case many operators have not yet absorbed, a court held that a software system’s output can be treated as a product for liability purposes rather than as protected speech — which opens the door to product-liability theories anywhere technology touches a vulnerable population. Memory care is squarely within that line.
Notice what none of these cases required: a new statute written for the technology. They were decided on contract law, on consumer-protection statutes older than the personal computer, on the False Claims Act, on ordinary product-liability doctrine. The legal infrastructure to hold operators accountable for technology failures already exists. Leaders waiting for purpose-built legislation before they tighten governance are exposed under the law exactly as it stands today.
What to Require Before You Scale
If the four questions are the diagnostic, the cure is a short list of things a leader should insist on before any technology moves from pilot to production. None of it is exotic. All of it is the difference between a defensible incident and an indefensible one.
Define the pilot narrowly: one use case, one named owner, one threshold for success and one for failure. A “pilot” that is really production under a softer name is the most common governance failure I see. Insist on a genuine human-review point — a place where a person can override the tool before its output changes care or operations — and confirm that staff are trained to use it, not merely told it exists. Know your data: what the tool uses, where it goes, and who can see it, because vendor access expands privacy and security exposure long before any adverse event. Align the contract and the insurance before signing, not after a loss: the business-associate agreement, the indemnity, the notice duties, and whether your coverage actually responds to a technology-influenced decision. And monitor continuously — audit logs, performance drift, incident review, and retraining of the staff, not just the tool.
Capability Is Not the Constraint. Governance Is.
The pattern underneath every technology failure is the same, and it is oddly reassuring: each one turns on a governance gap that predated the technology. An override pathway that was never built. A consent process the vendor quietly pushed downstream. A pilot that was really production wearing a different name. A vendor accuracy claim no one asked the vendor to substantiate. The technology did not create those gaps. It exposed the governance the organization already had — or did not.
That is good news for leaders, because governance is the part they control. No one can slow the pace of the tools. Anyone can decide who owns what before deploying them. In my experience, the organizations that handle these incidents best are not the ones with the most advanced technology. They are the ones that named the owner, built the override, and wrote down the escalation trigger before anything went live.
Technology may accelerate the decision. It does not dilute the accountability. It delegates the task — never the duty. Pilot deliberately. Train relentlessly. Escalate early. And whatever the tool turns out to be next year, keep asking the same four questions.
Facing one of these questions right now? Talk to us.
If a tool-related incident has you asking who’s accountable, we can help you find your footing — fast.
Contact Adelman Firm → www.adelmanfirm.com/contact