A Voice Says "Call the Nurse": Scoping an Honest Care-Alert Prototype

Some people find it hard to press a call button. Tremor, rigidity, or simply being on the floor after a fall — the button assumes a hand that can reach it. A voice doesn’t. That observation is the entire reason EchoCare exists.

The prototype is small: say “Alexa, call the nurse,” and an AWS Lambda function asks Twilio to place a real phone call, with a Japanese text-to-speech message, to one pre-configured number. Alexa Skills Kit in, PSTN out. About a hundred lines of Node.js.

The temptation

Here is the uncomfortable part. The demo is convincing. You speak to the room, and seconds later a phone rings somewhere else. It feels like an emergency alert system — and the first version of our own README called it something close to that.

But look at what the code actually guarantees:

• One hard-coded recipient. No routing, no fallback.
• No delivery confirmation. If the call fails after Twilio accepts it, nobody is told.
• No identity. Anyone speaking near the device can trigger it.
• No escalation. If the recipient doesn’t answer, the story ends there.

None of these are exotic gaps — they are exactly the features that make a real nurse-call system a safety product. A device someone might rely on in a bad moment must not feel more capable than it is. In care technology, the gap between demo and product isn’t polish; it’s responsibility.

The rename

So we renamed it. On veai.jp and in the repository, EchoCare is now labeled a research prototype, with the limitation stated in the first paragraph: not currently available for clinical or emergency use. We keep a three-tier status vocabulary across everything we publish — released, in development, research prototype — and the site and the README must always agree.

This wasn’t a marketing downgrade. It was the moment the project became honest about its own scope, and honestly scoped prototypes are more useful: they tell you precisely what remains to be researched.

What the prototype actually taught us

Even a hundred lines answer real questions:

1. Latency is acceptable. Voice intent → Lambda → Twilio → ringing phone lands in a few seconds. The serverless hop is not the bottleneck.
2. The interface disappears. Nobody needs training to say a sentence. For users who find touchscreens hostile, this matters more than any UI work we could do.
3. The hard problems are all downstream. Who should be called, in what order, and what happens when nobody answers — the routing and acknowledgment layer is the product. The voice trigger was the easy part.

Where this goes

The long-term concept is not “an Alexa skill.” It is a care-alert platform with replaceable edges:

Inputs                     Core                        Outputs
voice / dedicated button → alert backend             → LINE / staff app /
tablet / Alexa             (identity, routing,         existing nurse-call
                            priority, history,          systems / dashboard
                            escalation)

Alexa is one experimental input. LINE — which we already use in GutPacer’s notifier — is one candidate output. The research questions in the middle are the ones worth spending years on: false-trigger handling, network-failure behavior, and acknowledgment semantics (“the call rang” is not “help is coming”).

Until those are answered, EchoCare stays a prototype, and it says so in the first paragraph of everything we write about it. The code is open — read it in about the time it took to read this post.

---

EchoCare is part of the VEAI LAB. ecosystem, where every product carries the same three-tier honesty label — see where each one stands. If you are building voice interfaces for care settings and have opinions about escalation semantics, we would genuinely like to hear them: info@veai.jp.