The UK’s move from analogue landlines to digital phone services is expected to be largely completed in 2027. The government’s Telecare National Action Plan states that most customers can expect their telephone lines to have switched by the end of January 2027.
For telecare providers, migration involves more than replacing an analogue unit. The new endpoint must work with the selected connection, alert route, monitoring platform and operating procedure. Voice, location, power resilience and failure recovery also need to be tested before wider deployment.
This guide is intended for telecare providers, alarm receiving centres (ARCs), local authorities, housing providers, care organisations and system integrators planning a wearable upgrade.
What the UK Digital Switchover Changes for Telecare Services
The transition replaces the ageing public switched telephone network (PSTN) with digital phone services that use internet protocol technology. The Telecare National Action Plan applies to England, while the underlying phone-network changes also affect Scotland, Wales and Northern Ireland. Providers operating across the UK should distinguish England-specific policy from arrangements in each devolved nation.
Telecare requires particular attention because it is an end-to-end monitored service. A wearable button, pendant or home alarm is only the endpoint. The alert must still reach an ARC or another responsible team in a form that can be understood and acted on.
The Action Plan estimates that about two million people in the UK use telecare and warns that analogue devices can be less reliable when connected to digital lines. It calls for compatible, functioning telecare to be in place before migration, the eventual phase-out of analogue-only equipment and interoperability between devices and ARCs.
These goals do not amount to a blanket approval for any particular watch. Readiness must be demonstrated for the actual device, connection, platform and response process used by the service.
Map the Existing Service Before Selecting a Wearable
A migration project should begin with an inventory rather than a product catalogue. Record the users and sites covered, installed equipment, fixed and mobile connections, SIM providers, monitoring platforms, response routes, charging processes and the organisation responsible for each part of the service.
A responsibility table can expose gaps before procurement begins:
| Service component | Current owner | Migration decision | Evidence required |
| Wearable or home alarm | Telecare provider or equipment supplier | Retain, upgrade or replace | Model, firmware, connection method and compatibility test |
| Fixed or mobile connection | Communications or connectivity provider | Continue, migrate or redesign | Coverage, service plan, voice/data support and resilience |
| Device cloud or interface | Device or platform supplier | Integrate, adapt or replace | Interface specification, event tests and support owner |
| Alarm receiving centre | Service provider or ARC partner | Confirm interoperability | End-to-end event receipt and operator workflow evidence |
| Response process | Care organisation or monitoring team | Retain or revise | Acknowledgement, escalation and closure procedure |
Higher-risk users and sites should be prioritised according to the provider’s safeguarding and operational policies. A technology supplier can help identify technical dependencies, but it should not create a clinical risk score for the service.
For organisations planning elderly-care and telecare wearable deployments, this service map also helps separate device requirements from broader operational changes.
Choose a Connectivity Path That Fits the Service
Telecare programmes may use fixed or broadband-connected equipment, standalone cellular endpoints or a hybrid design. A cellular wearable can reduce dependence on a home landline, but a “4G” label alone does not establish suitability.
Confirm the following for the proposed model:
- supported LTE bands and UK operator compatibility;
- SIM or eSIM ownership, provisioning and replacement;
- voice-service support and call routing;
- indoor and outdoor coverage at representative sites;
- the effect of roaming arrangements; and
- device behaviour after losing and regaining service.
Network longevity also matters. Ofcom’s guidance for IoT and third-party device suppliers confirms that UK 3G networks are now switched off. The remaining 2G networks have operator-specific retirement schedules, and changes to inbound roaming can affect devices that use international roaming SIMs.
Review the relevant network timetable during procurement and again before rollout. Replacing an analogue endpoint with equipment that depends on a network with limited remaining life only postpones the migration risk.
A configurable medical alert watch may support cellular alerts, voice, location and platform connection, depending on the chosen model and configuration. Each capability still needs project-specific evidence.
Define Alert Delivery Before Comparing Devices
An alert workflow should show what the system knows at each stage. A button press does not prove that an operator received the event, and technical delivery does not prove that a person accepted responsibility.
Keep the following states separate:
- Triggered: The wearer pressed SOS or the configured logic identified a suspected fall.
- Transmitted: The device attempted to send the event through an approved route.
- Received: The server, platform or ARC accepted the event technically.
- Acknowledged: An authorised person or workflow accepted responsibility.
- Responding: The responsible party began the required action.
- Closed, cancelled or unresolved: The event reached a recorded disposition.
The event specification should cover identifiers, timestamps, trigger type, location status, battery and network state, confirmation or cancellation status, acknowledgement and final outcome where supported.
For automatic alerts, decide whether the wearer receives a vibration, on-screen prompt or cancellation period before transmission. Fall detection should not be presented as a guarantee that every fall will be detected.
Escalation routes will differ between family-contact services, staffed monitoring centres and housing-provider response teams. The provider must define the policy; the device and platform must demonstrate that they can support it.
Test Voice, Location, Power and Charging Resilience
Voice, data and location are related, but they are not interchangeable.
A watch may send an alert while a voice call fails. It may establish a call before a current location is available. It may return a last-known position that is no longer suitable for operational use. The platform should display each state independently and attach a timestamp and status to location information.
Testing should cover:
- indoor and outdoor voice quality;
- call setup and failure states;
- weak-signal and no-service behaviour;
- current, stale and unavailable location;
- data recovery after reconnection; and
- what the wearer and operator see during each condition.
Power resilience must be assessed across the whole chain. Digital home-phone equipment normally depends on mains-powered broadband equipment. Ofcom’s migration guidance requires communications providers to offer at least one hour of power resilience, free of charge, to eligible customers who rely on their landline to call emergency services during a power cut.
That requirement is not a universal telecare-watch battery standard, and it does not guarantee uninterrupted telecare calls. The government Action Plan explicitly notes that there is no regulatory obligation on communications providers to guarantee uninterrupted access for telecare devices.
The service therefore needs its own resilience assessment, including wearable battery runtime under the intended GPS, reporting and voice profile; charging routines; low-battery alerts; missed-charge procedures; router or hub backup; mobile-network availability; and platform continuity.
Record Platform and ARC Readiness Evidence
For a switchover project, the immediate integration question is whether the new endpoint can enter the existing alarm receiving centre or monitoring workflow without losing operational meaning.
Record evidence for:
- the event types and device-status information required by the service;
- successful receipt by the intended platform or ARC;
- the distinction between technical delivery and operator acknowledgement;
- how an interface outage and later recovery are shown; and
- the organisation that owns the adapter and unresolved integration faults.
For migration planning, limit this review to the evidence needed to preserve the existing service. Detailed payloads, authentication, versioning and interface architecture should be documented in a separate integration specification.
WearIntell can support project-specific API and firmware integration. The exact interface and evidence needed for migration must nevertheless be confirmed for the selected watch, firmware, platform and deployment.
Run a Controlled Pilot Before Wider Migration
A pilot should test the complete service in representative homes, facilities and coverage conditions. Testing only a successful SOS call leaves important failure paths unexamined.
| Scenario | Expected result | Evidence | Owner | Result |
| SOS under normal coverage | Event reaches the correct queue and follows the approved response route | Event ID, timestamps and operator record | Integration lead | Pass/Fail |
| Fall-alert cancellation | Cancellation is displayed correctly and is not treated as acknowledgement | Device and platform logs | Product owner | Pass/Fail |
| Delayed or duplicate event | Platform retains one operational event and records delivery history | Payload and audit log | Platform owner | Pass/Fail |
| Weak or unavailable network | Feedback and retry behaviour match the specification | Device log and platform state | Connectivity owner | Pass/Fail |
| Voice failure | Event remains active and follows the approved fallback route | Call result and event state | Service owner | Pass/Fail |
| Stale or unavailable location | Platform labels location accurately and continues the alert | Location timestamp and screen record | Platform owner | Pass/Fail |
| Low battery or device offline | Service receives the supported status and follows its maintenance process | Status event and support ticket | Operations owner | Pass/Fail |
| Platform outage and recovery | Events reconcile without being silently lost or falsely closed | Interface and audit logs | Integration owner | Pass/Fail |
Each scenario needs an expected device state, expected platform state, evidence, an owner and a pass/fail decision. Pilot size and acceptance thresholds should come from the provider’s risk assessment and deployment plan.
Telecare Wearable Procurement Checklist
Before approving a deployment, confirm that:
- target users, environments and response arrangements are documented;
- the proposed model, firmware, radio bands and SIM arrangement are identified;
- representative coverage and reconnection behaviour have been tested;
- SOS, fall, low-battery and offline event states are defined;
- receipt, acknowledgement, escalation and closure have named owners;
- voice, location and fallback behaviour meet the service requirements;
- battery life and charging procedures have been tested under the intended profile;
- the platform or ARC can process required events, retries and duplicates;
- access control, data retention and audit requirements are documented;
- certification and compatibility documents match the proposed configuration;
- successful, degraded and failed workflows meet pilot acceptance criteria; and
- supply continuity, firmware support, replacement and defect handling are agreed.
Approval should apply to the tested configuration, not to an unspecified product family.
Questions to Ask a Telecare Wearable Supplier
- Which exact watch model, modem, firmware and radio bands are proposed?
- Which UK operators and SIM arrangements have been tested?
- How are SOS, fall, low-battery and offline events represented?
- What proves technical receipt, and what supports human acknowledgement?
- How does the voice route behave when a call is not answered or cannot connect?
- How are current, stale and unavailable location states shown?
- Under what GPS, reporting, signal and voice conditions was battery life tested?
- What happens during network loss, platform outage and later reconnection?
- Which API documents, sample events, error codes and test tools are available?
- Which certification, operator and compatibility documents match the proposed configuration?
- How are firmware changes communicated, tested and supported after deployment?
- What technical assistance is available during pilot acceptance and rollout?
Prepare for 2027 as an End-to-End Service
Telecare migration must work at three levels: the endpoint, the integration and the operating procedure. A connected watch cannot compensate for an undefined response route, and a compatible platform cannot compensate for untested connectivity or charging processes.
Map the existing service, define the required event states, test normal and failure conditions, and approve only the configuration supported by the resulting evidence.
WearIntell supports telecare providers, monitoring services and connected-care organisations with medical alert watch projects involving cellular connectivity, alerts, voice, location, firmware and platform integration. Final capabilities depend on the selected model, network, software and project design.
Discuss Your Telecare Wearable Requirements: Share your UK service model, monitoring platform or ARC, connectivity plan, event workflow, pilot quantity and certification needs.
FAQs
What is the UK telecare digital switchover?
It is the migration from analogue telephone infrastructure to digital phone services and the related upgrade of telecare equipment and receiving systems. Providers must ensure that the device, connection, platform and response workflow continue to operate together.
When is the UK digital phone switchover expected to be completed?
The UK government’s Telecare National Action Plan says that most customers can expect their telephone lines to have switched by the end of January 2027. This should not be treated as one statutory deadline that applies identically to every provider, network and user.
Do all analogue telecare devices need to be replaced immediately?
Not necessarily. The government supports the eventual phase-out of analogue-only equipment but recognises that interim arrangements may be needed. Any retained, adapted or converted installation still requires risk assessment, compatibility testing and ongoing monitoring.
Can a 4G telecare watch work without a home landline?
A cellular watch may support alerts and voice without a home landline, depending on its hardware, SIM, operator, firmware and service configuration. Coverage, voice routing, platform connection and failure recovery must be confirmed for the intended deployment.
What should a telecare provider test before migration?
The pilot should cover successful alerts as well as weak coverage, voice failure, unavailable location, low battery, device disconnection, delayed or duplicate events, platform outages and recovery. The pilot matrix above provides a practical starting point.