A hospital chain's IT head brings a list from the board to the first call: on-device AI, wearables, AR for the maintenance team, and an app that adapts itself to each user. On a slide, all four look like the same kind of upgrade. On a nurse's three-year-old phone in a basement ward with no Wi-Fi, each one fails in its own way, and each adds a different kind of work to the build.
Four features, four kinds of work
It helps to sort the list by what each item adds before discussing whether to build it.
| Feature | What it adds to the build | What it depends on |
|---|---|---|
| Edge AI | A model packaged with or downloaded into the app | Phone memory, chip, battery |
| Wearables | A second device and a Bluetooth link | Pairing, OS background rules |
| AR | 3D content and camera tracking | Device support, lighting, assets |
| Adaptive screens | Rules or learned behaviour per user | Signals, logs, a reset option |
Only one of these is mostly a model problem. The others are device problems, content problems and trust problems, and they need different people.
Edge AI means the model lives on the phone
Edge AI means the model runs on the device instead of sending data to a server. The reasons that matter are plain ones. Voice, image and gesture recognition respond faster. Patient data stays on the phone. And the feature keeps working when the network does not, so a nurse doing rounds in a ward with poor signal is not left watching a spinner.
- Fast response
- Data stays local
- Works offline
- Needs a connection
- Data leaves the phone
- Easier to update and measure
Neither side wins outright; many apps split the work between them.
The catch is that the model has to fit the phone. RAM, storage, battery and chip capability vary widely across the handsets a hospital's staff carry, and a model that runs well on a new phone can be unusably slow on a three-year-old one, or get the app killed for using too much memory. The split we usually suggest is a small on-device model for the quick tasks and a server model for the heavy ones. Where that server model should live, a hosted service or open weights in your own cloud, is its own decision, and our post on hosted versus open-weight models sets out the trade-offs.
Updating the model is a release question too. Either it ships inside the app, which means store review every time it changes, or the app downloads it separately, which means you now own a download pipeline. Test what happens when that download stops halfway on a hospital guest network. The app should keep using the old model, not crash on a half-written file.
A wearable is a second device with its own limits
Health alerts, hands-free instructions and tap-to-pay all depend on the app talking to a watch or a band. The phone is usually the hub: the wearable collects readings, the phone app processes and stores them, and the backend keeps the history and raises alerts.
- 01Wearablesensor reading
- 02Phone appprocess, store, queue
- 03Backendhistory, alerts
Each arrow is a connection that can drop; the phone has to queue readings until it comes back.
This is where it gets messy. Bluetooth connections drop when the phone goes into a pocket or a locker. The OS limits what an app can do in the background, and those limits differ between Android makers and change with OS updates. Battery saver modes on many Android phones stop background work without telling anyone. So the app has to queue readings on the device and send them when the connection comes back, with timestamps from the wearable, not from when the phone finally synced.
Wording needs as much care as Bluetooth. A band that reports a heart rate is one product. An app that says the reading is abnormal is a different product with a different approval path, and the hospital's legal team should see that wording before the developers do.
AR has to be useful, and also optional
Showing a maintenance engineer an overlay on a dialysis machine is a reasonable use of AR. It needs tracking that holds up in a badly lit plant room, 3D assets that someone produces and keeps current every time the equipment changes, and phones that support it at all.
Because support varies, every AR task needs a non-AR way to finish. The engineer on an older phone should still be able to open the service manual for that exact machine, with the same steps in text and photos. If AR is the only path, the people with the cheapest phones are the ones locked out.
Adaptive screens need rules before learning
Personalisation can be as simple as a ward nurse and a hospital administrator seeing different home screens. That version is a rule: this role sees this layout. Learned adaptation needs much more. It needs signals to learn from, a way to check it is behaving sensibly, and a way for the user to see and change what the app has decided about them.
An interface that rearranges itself without warning is harder to use, especially for someone using it with gloves on in a hurry. Start with explicit rules and add learning only where rules clearly fall short. Keep the logic in one place and log each decision, so when a nurse raises a ticket saying her shortcuts disappeared, support can tell her why. If the app explains a score or a recommendation to staff, our post on explaining a risk score to the person who acts on it covers that side.
How these features fail after launch
The model gets chosen before anyone runs it on a mid-range phone. The wearable feature gets tested on one watch and one OS version. AR is built as the only path. Personalisation ships with no reset. Privacy claims get made for on-device processing without anyone checking what still leaves the phone, and the analytics SDK usually does. And nobody owns evaluation, so a feature that was good at launch drifts for months before a complaint reaches someone who can act.
Before building any of the four, take the cheapest phone your staff carry and answer these on it:
- What does the user see when the feature is unavailable or wrong?
- Does it still work with battery saver on, storage nearly full, and no signal?
- What data does it read, and where does that data go, including through third-party SDKs?
- Who checks its output after launch, and how often?
- Can the user turn it off?
Start with the first. If the honest answer is "the app stops working", the feature is not ready, whatever the board deck says. When you get to scoping the model side, our AI solutions page lists the kinds of AI work we take on.
