Guidance

Digital telecare commissioning guidelines: personal alarm devices

Published 8 October 2026

Introduction

These guidelines are for commissioners and procurement teams responsible for planning, procuring or reviewing telecare services.

They have been produced by FarrPoint Limited on behalf of the Department of Health and Social Care (DHSC) and focus on the technical and service requirements that help ensure digitally enabled telecare services are safe, resilient and reliable for people who depend on them.

The guidelines have been developed in response to the:

• increasing use of digital telecare technologies
• migration from analogue services
• growing importance of connectivity, interoperability and cyber security in widely used telecare services

They have been informed by engagement with commissioners, providers, suppliers and sector partners, alongside an independent technical review of current telecare products, services and assurance approaches.

These guidelines use the following terminology:

• commissioner: the organisation buying digital telecare equipment or service - this could be a local authority, housing provider, third-sector organisation or commercial provider
• provider: the organisation responsible for delivering the digital telecare solution to the service user - this could be the commissioner or a third-party service provider that they’ve commissioned
• supplier: the organisation that is providing the digital telecare requirement or service
• bidder: a supplier that is responding to the tender specification

What the guidelines cover

These guidelines focus on technical and service considerations that commissioners may wish to address when procuring digital telecare solutions, including:

• interoperability and implementation of digital telecare standards
• connectivity and resilience requirements
• service management and supplier service levels
• cyber security and data protection
• access to operational and performance data

The guidelines are not intended to prescribe a single procurement approach. The requirements are intended to support informed procurement decisions and should be adapted to reflect local circumstances, service models and user needs.

The requirements in this guidance focus on existing reactive telecare services, where support is triggered by an alert from an individual within their home. These services are likely to continue to play an important role as part of a broader care technology offer. Commissioners therefore need to know that they are safe, reliable and capable of meeting the needs of the people who depend on them.

Digital telecare migration

To fully implement the requirements detailed in this guidance, all elements of telecare solutions should support them. For example, to use fixed broadband connectivity (internet connectivity provided using a fibre or cable connection instead of using a mobile network), both the alarm devices and alarm receiving centre (ARC) must support this. This means commissioners should have a plan for migrating each element of their telecare solution to digital.

Although commissioners are likely to have an existing plan to prepare for the analogue telephony switch-off, this may take some time to complete, meaning commissioners should consider buying solutions that work with their existing telecare equipment (known as backwards compatibility). This will allow for a phased migration to the solution found by using the requirements in this guidance.

Relationship to existing frameworks and assurance schemes

These guidelines are non-statutory and do not replace existing standards, assurance schemes, procurement frameworks or local governance requirements. Instead, they provide commissioners with additional procurement guidance focused on technical, resilience and connectivity considerations that are not always covered consistently elsewhere.

Other frameworks and schemes can provide evidence of organisational quality, safety processes, service maturity and good practice. Commissioners can refer to these as part of a wider procurement and assurance approach. For example:

• TEC Services Association’s quality standards framework, which assesses organisations against a range of service quality and operational requirements
• procurement frameworks such as ESPO’s technology enabled care framework

There is not always a direct one-to-one relationship between the requirements contained within these technical guidelines and those in other frameworks or assurance schemes.

How to use the guidelines

Commissioners should consider including the following requirements in their specifications when procuring digital personal (also known as dispersed) telecare alarms and associated connectivity.

The requirements are not prescriptive. They are designed to provide best practice that supplements commissioners’ existing telecare requirements. This allows commissioners to tailor procurements to their service’s needs, combining the guidelines’ technical requirements with those relating to features and functionality, data collection, reporting requirements and so on.

The requirements relate to functionality similar to that offered by existing analogue alarm equipment. Some digital alarms provide additional functionality, such as proactive monitoring and integration with smart consumer devices. If a commissioner is including these as part of its telecare offer, they should add requirements to specify them.

In this guidance, each section contains:

• an overview of the benefits and issues that the requirements aim to address
• the requirements that commissioners may wish to include in procurement documentation and the confirmation that bidders should be asked to provide
• guidance on what commissioners should look for in bidders’ responses (that is, what a ‘good answer’ looks like)

1. Digital telecare standards requirements

Telecare suppliers have been using different approaches to implement digital telecare standards like alarm IP communication protocol (PD CLC/TS 50134-9) and social care alarm internet protocol (SCAIP) (SS 91100:2014). Telecare equipment can use different versions of the digital telecare standards, which can cause problems.

For example, different interpretations of standards can cause interoperability issues between alarms and ARCs so that each solution must be configured and tested individually. This increases the time, effort and risk of installation.

Also, the common practice of using virtual private networks (VPNs) and mobile network private access point names (APNs) to provide a secure connection limits and complicates connectivity resilience and constrains the ability to move between ARCs.

These issues can be significantly reduced if all suppliers follow a single version of the standards.

1.1. Alarm IP communication protocol standard

Alarm devices should meet the alarm IP communication protocol standard (PD CLC/TS 50134-9) in full.

Bidders should confirm their devices meet the documented standard (as published by the British Standards Institute (BSI)) and that no manufacturer specific or other variants have been used.

If any manufacturer specific or other variants have been implemented, details should be provided.

Evaluation guidelines

Bidders should confirm that their devices meet the standard in full. This should be the documented standard as published by BSI, and not include any variants outlined in other guidance documents or that are manufacturer specific.

There is currently no independent body that validates that an alarm device meets the BSI standard, meaning commissioners must rely on bidders’ assurances.

If variants to the standard are detailed in the response this increases the risk of interoperability issues. Commissioners should ask follow-up questions to understand the nature and impact of these variants.

Alarm devices that use only SCAIP should be avoided as this protocol has known security vulnerabilities.

1.2. Security

Bidders should confirm that their alarm devices use transport layer security (TLS) and secure real time protocol (SRTP) using AES-128 encryption to secure the end-to-end connection to the ARC for both signalling and voice, as defined in the documented alarm IP communication protocol standard.

Evaluation guidelines

To ensure solutions are secure and to reduce the risk of data loss, bidders should confirm that their devices use TLS (version 1.2 or above), SRTP and AES-128 encryption as defined in the alarm IP communication protocol standard. TLS and SRTP are security approaches used on almost all websites and internet-based applications. Both signalling and voice should be encrypted.

SRTP should be supported as a way to send voice to the ARC as this ensures support for fixed broadband connections, which adds resilience.

1.3. Backwards compatibility (optional)

This is an optional requirement. Commissioners should include this requirement if they need their alarms to have backwards compatibility with older ARCs or where dial-up is required as a backup option.

Bidders should state whether their alarm devices support the following to provide backwards compatibility:

• security provided by private APN and VPN connections
• dial-up phone calls to carry voice to the ARC

If they do, bidders should confirm that this is for backwards compatibility only and is in addition to using TLS and SRTP.

Evaluation guidelines

Private APN and VPN encryption may be offered to ensure alarms can connect to older ARC solutions, but this should only be in addition to TLS and SRTP.

Solutions that can only operate by making a phone call to carry voice to the ARC should be avoided. Phone calls to the ARC are acceptable as a backup option (where used) and for compatibility with older ARC solutions.

2. Connectivity requirements

To ensure future-proof and resilient connectivity for telecare alarms, the devices should support a mix of 4G or 5G mobile and fixed broadband. Fixed broadband also provides an approach to connect service users in areas with no or unreliable mobile coverage.

These requirements relate to the connectivity options supported by an alarm device.

2.1. 4G and VoLTE

Bidders should confirm that alarm devices connected to a mobile network support 4G networks and voice over long-term evolution (VoLTE).

Bidders should also detail:

• how 4G connectivity and VoLTE is used by their alarm device and by the mobile network - this should include each of the mobile networks and other suppliers used to route voice and data traffic between the alarm and ARC
• how reliable connectivity and VoLTE capability will be evidenced for the commissioner’s service users, including any limitations on the available networks or VoLTE capability due to roaming agreements or coverage. If evidence does not already exist, bidders should state how it will be provided

Evaluation guidelines

2G networks are being switched off between 2029 and 2033, so responses should confirm that any mobile connectivity uses 4G as a minimum for future-proofing.

VoLTE should be implemented to ensure the alarm can carry voice using a dial-up call if required (for resilience and backwards compatibility with older ARCs).

VoLTE is a mobile technology that allows mobile phone calls to be made using a 4G mobile network. If a 4G device does not use VoLTE, any phone calls it makes use the 2G network (as 3G is now decommissioned). As 2G networks are decommissioned, non-VoLTE 4G devices will be unable to make phone calls and cannot support analogue and digital telecare that rely on dial-up voice.

The roaming subscriber identification modules (SIMs) often used by telecare alarms can use several suppliers to provide connectivity, including overseas network providers. This means that providing telecare connectivity can involve complex traffic routes and subcontracting arrangements.

Bidders should demonstrate that reliable connectivity, including use of VoLTE, is available across multiple networks within the commissioner’s area and that any areas of no-coverage have been identified. If evidence does not already exist, bidders should state how it will be provided.

2.2. 5G connectivity (optional)

This is an optional requirement as 5G bandwidth is not currently required for telecare.

Bidders should provide details of any support their alarm device offers for 5G connectivity.

Evaluation guidelines

5G coverage is becoming increasingly available, meaning more telecare alarms may be able to access these networks.

2.3. Resilient connectivity options

Alarm devices should provide a range of resilient connectivity options using dual SIM, resilient SIM (rSIM), embedded SIM (eSIM) and fixed broadband connectivity. Bidders should provide details of the connectivity options supported by their alarm devices.

Evaluation guidelines

Bidders should offer at least one connectivity resilience option. The more options supported by an alarm device, the higher the level of resilience commissioners can provide to service users.

Dual SIM and rSIM are currently offered by several providers. Both options provide resilience by allowing the devices to use 2 mobile profiles, which protects against some mobile connectivity failures by allowing a second data route to be used if the first fails.

eSIM is a SIM that is embedded in a mobile device rather than on a physical card. eSIMs provide more flexibility than a physical SIM card, allowing a device to use multiple mobile plans and switch between them quickly.

The best approach is to use a mix of fixed and mobile broadband connectivity. This minimises single points of failure such as a local mobile mast failure, which could mean a loss of connectivity for devices that are reliant on mobile connectivity and only have coverage from a single network operator.

2.4. Connectivity without roaming SIM (optional)

Alarm devices should provide mobile connectivity that does not rely on using a roaming SIM. This is an optional requirement.

Bidders should provide details of the resilient mobile connectivity SIM options supported by their alarm devices that do not rely on a roaming SIM.

Evaluation guidelines

It is desirable that bidders offer a solution that does not rely on international roaming SIM to provide mobile connectivity. This is because these SIM cards have complex data traffic routing (often through mainland Europe and using a number of providers) and are expensive.

Alarm devices should support either dual SIM cards (where resilience is provided by using 2 cards from different networks) or an eSIM.

2.5. Fixed broadband internet connection

Bidders should provide details of the support their alarm devices offer for encrypted signalling and voice to the ARC over a fixed broadband connection. This connection should use TLS and SRTP encryption as defined in the alarm IP communication protocol standard.

Evaluation guidelines

Alarm devices should support fixed broadband connectivity for both voice and signalling (with encryption).

Fixed broadband provides a connectivity route:

• that is independent of the mobile networks so can increase resilience
• in areas with no or unreliable mobile coverage

Responses should be considered unacceptable if the alarm devices (one of the following):

• can only carry voice using a dial-up phone call
• do not encrypt data end-to-end

3. Service management and service level requirements

Personal telecare alarms are often sold inclusive of connectivity (usually a mobile SIM card) designed to keep the devices connected reliably 24 hours a day, 7 days a week.

Some telecare suppliers’ arrangements for supporting their alarms and connectivity may offer limited or no service level guarantees, or lack suitable processes to support devices 24 hours a day, 7 days a week.

The requirements in this section clarify the supplier’s responsibilities, particularly when faults occur. They also define service availability levels to ensure that alarm reliability reflects the safety-critical nature of telecare.

To provide these service levels, suppliers should use well-established IT industry service management processes, the most widely used being Information Technology Infrastructure Library (ITIL). These processes will ensure suppliers better support digital devices, which are more complex to manage than their analogue equivalents given the:

• range of technologies used
• real-time information on system performance
• need for more frequent software updates to keep them secure and to add new functionality

Commissioners should note that to ensure service continuity during a power outage appropriate battery backup needs to be in place for alarm devices and any associated network equipment, as well as resilient mobile or fixed broadband connectivity.

3.1. Service availability levels

Where the bidder is providing alarm devices inclusive of connectivity (that is, with SIM or fixed broadband connectivity) they should provide service availability levels for the connectivity.

These service levels should be designed to measure faults that cause multiple alarms to fail. It is not expected that individual alarms would be covered.

Availability levels should not be less than 99.9% defined annually and measured on a 24 hours a day, 7 days a week basis.

Bidders should:

• define and measure availability from alarm to ARC to ensure that it reflects the end-user experience
• give details of the connectivity service level that will be provided in terms of percentage availability time
• give details of how availability is defined (that is, what constitutes a fault) and how it is measured

Evaluation guidelines

The bidder should provide details of their availability service level. The service level should cover all shared elements of the connectivity solution - for example, core network, data centre, VPN connections and so on.

Responses should give a clear definition of what constitutes a fault and what effect it will have on the availability service level. (A long fault or a lot of short faults may reduce the availability achieved below the 99.9% target.) If the definition is unclear, it is unlikely to be measurable or enforceable in practice.

Faults are likely to be defined as where multiple alarm devices are affected, for a minimum amount of time - that is, more than XX alarms unavailable for over YY minutes. The commissioner will need to determine whether the proposed values of XX and YY proposed are acceptable based on operational criteria.

It is unlikely to be practical or desirable to obtain service levels for individual alarm devices because of the number of alarms being monitored. These service levels will be triggered repeatedly and could be caused by local indoor mobile coverage issues, for example. Individual alarm failures will still be reported to the provider by the device management platform (DMP), meaning that individual alarm performance can be analysed, if needed.

A DMP is an online portal used to monitor and configure telecare alarm devices. Some suppliers call it a cloud management portal (CMP).

To reflect the end-user experience, availability should be measured from alarm to ARC, not from alarm to a DMP (where used).

Once availability service levels are defined, commissioners should include these in service contracts to ensure the supplier is contractually committed to providing them and to clarify any responsibilities the commissioner has.

Service availability is the time for which a service is operating and usable. It is typically defined as a percentage over a given measurement period. A service is not available if it has failed completely or performance is severely degraded.

The requirement uses a suggested availability of 99.9% measured annually, which is 8 hours of downtime a year. This is common in the IT industry and should be achievable for alarms with resilient connectivity. This figure is higher than in other guidance but is considered appropriate for a safety-critical service such as telecare.

Commissioners should determine what level of availability they need to provide to their service users (keeping in mind no solution can provide 100% availability) and use this to define the minimum availability level in this requirement.

Downtime in hours a year is calculated using the formula 8,760 × (1 – availability percentage). For example, a 99.9% availability is a downtime of 8,760 × (1 – 0.999) = 8.76 hours a year.

This service level refers only to connectivity. The availability of other elements of the telecare solution (that is, the ARC) will be defined separately (see Digital telecare commissioning guidelines: alarm receiving centre solutions).

3.2. Proactive monitoring

Where a connectivity fault impacts a provider’s alarm equipment, the supplier should provide proactive and provider specific information on the fault and its effect (that is, which of the provider’s alarms are affected and how).

Information should come from the supplier directly. The provider should not need to ask a connectivity supplier or mobile network operator for information.

Bidders should detail:

• what proactive monitoring they will complete
• how they will report a fault to the provider
• what information they will provide

Evaluation guidelines

Responses should detail arrangements for proactively contacting the provider if there is a connectivity fault, including outside office hours.

Using proactive monitoring means the supplier should not wait for a provider to report a fault before starting to resolve it. They should identify the issue themselves and tell the provider what has happened and what is being done to resolve it.

Information should come from the supplier directly. The provider should not need to liaise with a connectivity supplier or mobile network operator to obtain information.

Information on the fault should be specific to the provider, detailing which types of alarm are affected and what it means for services. It should not be a generic update, like: “We are seeing degradation on new data sessions.”

A good example is: “All alarm devices will be unable to connect to the [mobile provider’s] network if they reboot or try to roam. Alarms that roam will connect to another mobile network and continue to operate normally if coverage is available.”

3.3. Service management arrangements

Bidders should provide details of the service management processes they have in place to monitor and report on solution performance and to manage faults.

Evaluation guidelines

Bidders should provide details of recognised service management procedures that they have implemented. ITIL is the most common IT industry standard.

3.4. Service desk arrangements

Bidders should provide details of the service desk arrangements they have in place to allow providers to report faults 24 hours a day, 7 days a week.

Responses should also include detail of when and how the service desk communicates updates on service faults back to the provider.

Evaluation guidelines

Bidders should have a service desk that allows faults to be reported on 24 hours a day, 7 days a week. This ensures that faults that occur outside normal office hours can be reported and rectified.

Service desks should have processes to regularly update the provider on progress in resolving the issues. For high-impact faults (potentially affecting large numbers of alarm devices), hourly updates should be expected.

3.5. Service reporting

The supplier should offer regular (ideally monthly) reports to the provider on:

• service availability
• issues and faults
• outstanding support requests
• planned maintenance
• feature updates

Bidders should provide details of the service reporting they will provide, including:

• the content of the reports provided to the customer
• how often reports will be provided

Evaluation guidelines

Service reporting ensures providers can see:

• how their solution is performing
• that the supplier is meeting agreed service levels

Bidders should explain what will be in their regular reports (ideally monthly), including:

• any faults that have happened during the previous reporting period, their root cause, and what is being done to prevent recurrence
• service availability for the year (if connectivity is provided with the alarm)
• details of any outstanding support requests and their status
• details of the timing and nature of any planned maintenance - including whether it will affect the service
• details of any upcoming feature updates

3.6. Release management processes

Bidders should provide details of their release management processes, including:

• the frequency of releases
• pre-release testing
• release processes including rollback
• the information given to providers on the nature and timing of releases

Evaluation guidelines

Digital devices and DMPs need regular updates to:

• keep solutions secure
• deal with software defects (bugs)
• add new features

To avoid releases causing service issues, bidders should show they have processes in place for updating their solution, including regular releases with associated testing, implementation and rollback plans.

Before carrying out an upgrade, bidders should tell providers when it’s happening and what it involves, especially if the upgrade will affect the service. Providers should be allowed to agree the timing of any upgrade that will make the service unavailable.

4. Cyber security and data protection requirements

The move to digital means alarm devices are connected to the internet and exposed to cyber security and data protection risks that analogue equipment was not. Robust technical and organisational security controls are needed to make sure that user data and the solution security are kept safe.

The requirements in this section define a minimum level of controls that commissioners should ask bidders to have in place.

The nature of the data processed and the technical solution used to provide a telecare service vary between providers. To ensure appropriate controls are in place, commissioners should complete a data protection impact assessment (DPIA) to identify and minimise data-related risks. The output of this assessment can be used to update the technical and information security management requirements, if relevant.

4.1. Cyber security accreditation

Bidders should have cyber security accreditation (one of the following):

• ISO27001 - the international information security management systems (ISMS) standard
• Cyber Essentials or Cyber Essentials Plus
• an equivalent standard

The accreditation should cover the equipment and services the bidder is proposing in its response to the commissioning specification document.

Bidders should provide details of the cyber security accreditations for:

• themselves (with a copy of the certificate)
• any subcontractors they use for elements of the solution

Evaluation guidelines

Bidders should provide a copy of their certification from an independent assessor.

The certification should be in date and cover the scope of equipment and services in the bid, including any subcontracted elements.

ISO27001 is an international standard for ISMS. It uses a risk-based framework to protect data confidentiality, integrity and availability.

Cyber Essentials is a certification scheme designed to prevent the most common internet-based cyber security threats by ensuring organisations use the minimum standard of cyber security recommended by the government. Organisations are certified to Cyber Essentials using a combination of self-assessment and an independent audit by an external assessor. Cyber Essentials Plus certification uses a greater level of external testing.

Where bidders propose an equivalent standard, commissioners will need to confirm that it provides like-for-like protections to ISO27001, Cyber Essentials or Cyber Essentials Plus.

4.2. Cyber security risk management process

Bidders should provide details of their cyber security risk management process, including:

• governance and risk ownership
• asset identification
• risk identification and assessment
• risk register
• risk treatment and controls
• monitoring and review
• any responsibilities the commissioner has for risk management

Evaluation guidelines

Bidders should show they have a defined process in place for identifying, assessing and controlling cyber security risks. These risks could relate to ransomware, system failure, insider threats, supply chain issues and so on.

Responses should address each of the defined elements.

Responses should also give details of any responsibility placed on the commissioner to assist with risk identification or control.

4.3. Cyber security incident response process

Bidders should provide details of their cyber security incident response process, including:

• detection
• assessment
• response and recovery
• communication and reporting
• responsibilities (including those placed on the commissioner)
• timescales
• lessons learned

Evaluation guidelines

Bidders should show they have a defined process in place for proactively identifying and responding to cyber security incidents. These incidents could relate to a denial of service attack, unauthorised system access, ransomware and so on.

Responses should cover each of the defined elements and include timescales for:

• detection
• completing the main response tasks
• informing the customer that an incident has been detected

Responses should also give details of any responsibility placed on the commissioner to assist with detection or response.

4.4. Legal requirements

Alarm devices should comply with the Product Security and Telecommunications Infrastructure Act 2022 (PSTI).

Bidders should provide details of how they comply with this legislation, including:

• a statement of compliance
• the process and timescales for reporting and remediating vulnerabilities
• the length of time security updates will be provided for alarm devices

Evaluation guidelines

PSTI mandates security requirements for UK consumer connectable (‘smart’) products. It is a legal requirement that bidders’ equipment meets PSTI.

Bidders should provide a statement of compliance and their process for reporting and remediating vulnerabilities.

Bidders should provide security updates to cover the expected life of the alarm equipment to avoid providers using potentially insecure devices.

4.5. Penetration testing

Alarm devices and any associated DMP (if used) should be independently penetration tested once a year and after any major software updates. A penetration test is an authorised simulated cyberattack on a computer system.

Bidders should provide copies of their most recent penetration test, or a summary of vulnerabilities identified, with a remediation plan for any high or critical vulnerabilities.

Bidders should also provide details of how often penetration tests will be completed during the life of the solution.

Evaluation guidelines

Bidders should provide a copy of a penetration test, or a summary of vulnerabilities identified. This must be completed by an independent tester, ideally with CREST, CHECK or Cyber Scheme accreditation.

Commissioners should consult their cyber security and data protection teams to determine whether any vulnerabilities highlighted are acceptable.

Any high or critical vulnerabilities identified in the penetration test should have a clear remediation plan with associated timescales.

Bidders should commit to annual penetration testing to ensure that alarm devices and the DMP remain secure after any software updates or configuration changes.

4.6. Data protection

Bidders should provide details of how their solution meets the requirements of the Data Protection Act 2018 (DPA) and the General Data Protection Regulation (GDPR).

Bidders should also confirm if any data is stored or processed outside the UK or EU.

Evaluation guidelines

Bidders should show compliance with DPA and GDPR.

Responses should include calls between the alarm and ARC as these could include sensitive subjects - such as health and care requirements and personal details of family or carers.

Commissioners should consult their cyber security and data protection teams to determine whether any issues highlighted are acceptable.

4.7. Backup systems

Bidders should provide details of the business continuity arrangements in place to ensure DMPs (where used) and any other required solution elements remain available if the primary system fails.

Responses should include details of:

• any backup system or alternative arrangements used to rapidly provide a replacement for the DMP and any other required solution elements if the primary system fails
• how often provider data is backed up
• the expected data recovery time
• any data that is not backed up
• the time it takes for the backup system to take over when the primary system fails
• whether the backup system starts automatically or whether the supplier needs to start it
• whether alarms will continue to operate in the period between the primary system failing and the backup system becoming available

Evaluation guidelines

Bidders should demonstrate that they will be able to quickly establish a replacement DMP or service if the primary system fails.

Bidders should also provide business continuity plans for any other technical elements the solution needs for it to work - for example, other cloud services or communications infrastructure.

The solution should regularly back up all data relating to a provider’s alarms, such as configuration, historical status logs and so on. Bidders should provide details of how long it will take to restore the data onto a backup system. The frequency of backups and restore timescales should be defined by the amount and nature of the data stored. Data generated between backups may be lost if the system fails.

When evaluating the timescales for making the backup system available, commissioners should consider whether or not alarms can operate if the primary system fails. Shorter restore timescales are likely to be needed if alarms are unable to function.

5. Data standards requirements

Digital telecare alarms provide similar data as analogue devices on mains power and battery failures, test calls and so on. However, they may also provide data relating to the device’s connectivity, such as:

• whether it’s connected
• which network it’s connected to
• how strong its signal is (for mobile connectivity)
• whether it has attempted to roam (for mobile connectivity)

Often, this connectivity data is stored and viewed using a DMP instead of the ARC solution, where other status data is stored and viewed. Providers using alarms from multiple manufacturers may need to access and monitor several different DMPs.

The data on alarm connectivity, alarm configuration and other status messages should be easily accessible to allow providers to obtain an end-to-end view of alarm configuration, performance and the end-user experience. Access to this data should be provided using data export or an application programming interface (API). This allows it to be accessed by other systems or for offline analysis to be completed.

An API is an agreed set of protocols and data formatting that allow data to be extracted and updated. APIs can be used to integrate software applications and share data between them.

5.1. Alarm build and performance

The solution should provide full access to data relating to alarm build and performance.

As a minimum, the solution should provide the ability to export the following in an open and editable format without support from the supplier:

• alarm software build and configuration data
• peripherals used and status
• live and historical alarm connectivity data, such as:
  • connectivity used (fixed or mobile)
  • connection status
  • mobile network used
  • connection strength
  • roaming events

Bidders should provide details of how data access is provided, its format and the data fields available.

Evaluation guidelines

Bidders’ responses should confirm that they offer an export capability that provides data in an open and editable format.

Providers should be able to complete exports themselves and not have to ask the supplier to do it for them.

Ideally all data fields should be exportable, although some bidders may only support a subset. Providers will need to determine whether the data supported is enough to provide full reporting capability.

5.2. API offering

The solution should offer an API for the device management platform to allow other systems to access and update (where applicable) alarm and event data.

The API should be secure and published.

Bidders should provide details of any API capability offered by their solution, including:

• how it is accessed and secured
• the data fields that can be accessed and updated

Evaluation guidelines

Bidders’ responses should confirm that they offer an API.

Ideally the API should be live. If the API is an improvement planned for the future, bidders should provide committed timescales for it.

Ideally the API should allow all data fields to be accessed and updated (where relevant) - however, some bidders may only support a subset. Providers will need to determine whether the data supported is sufficient to provide integration capability.

6. Provider obligations requirements

Digital telecare solutions are likely to use technology provided by several organisations. For example, a digital personal telecare alarm may use the service user’s broadband connection, while the provider is responsible for the devices (such as computers, tablets or phones), multi-factor authentication and so on, to allow staff to access the DMP.

The requirements in this section aim to understand the technical infrastructure, data and support that the provider, other suppliers and service users need to provide to allow the solution to operate. Commissioners should evaluate the answers to these questions to make sure that the detailed resources can be provided and bidders’ responses can be evaluated on a like-for-like basis.

6.1. Technical infrastructure and facilities

Bidders should give details of the technical infrastructure and facilities that must be in place to support their solution. These could be the responsibility of the provider, third-party suppliers or service users.

Responses should include any requirements for:

• client devices (PC or mobile)
• software applications
• networking - local area (including wifi), wide area or internet
• telephony (lines, handsets, soft phones or other telephony services)
• in-building cabling
• cyber security or authentication
• power
• equipment housing and cooling

Evaluation guidelines

Bidders’ responses should contain details of the infrastructure and facilities the provider or a third party is responsible for. It is unlikely that any supplier will be wholly responsible for an end-to-end solution, so commissioners should expect to see some responsibilities placed on themselves, third-party suppliers or service users.

Any responsibilities detailed in the response should be described in enough detail to allow the commissioner to establish whether they are able to provide the infrastructure and facilities, and at what cost. This will ensure solutions are deliverable and that bidders’ responses are compared on a like-for-like basis.

6.2. Information, support and resources

Bidders should give details of the information, support and resources that must be provided to allow them to install and operate their solution. These could be the responsibility of the provider or of third-party suppliers.

Responses should include detail of any requirements for:

• data relating to service users or equipment
• resource to reconfigure existing equipment or services
• resource for acceptance testing
• resource or information to log and respond to solution faults

Evaluation guidelines

Bidders’ responses should contain details of the information, support and resource the provider or a third party is responsible for. It is likely that any supplier will need support to configure and test the solution. Commissioners should expect some of this to come from themselves or other suppliers.

Any responsibilities included in the response should be described in enough detail to allow the commissioner to establish whether they can provide the information, support or resource, and at what cost. This will ensure solutions are deliverable and that responses are compared on a like-for-like basis.

Commissioners should use the responses to this question to understand any responsibilities associated with service faults - specifically, any responsibilities that could potentially delay the logging of a solution fault. For example, if the provider is responsible for testing their own internet connection and other elements of their infrastructure before logging a fault with the supplier.

7. Case studies requirements

When procuring digital telecare, commissioners should ensure the solution they are buying is proven, meaning it is an existing product and has been shown to work in a live operational environment.

This avoids risks associated with procuring a solution that is still in development or untested operationally, such as:

• prolonged installation and testing timescales
• interoperability issues
• solutions that do not provide the full functionality originally promised

7.1. Operational use

Bidders should provide 2 case studies where their solution, as described in their response, has been used operationally.

Evaluation guidelines

Bidders’ responses should detail 2 case studies, which:

• use the same solution as proposed in their response, not a similar solution using a different solution version or configuration
• use a live operational environment, not lab-based testing
• operate at a reasonable scale to demonstrate the reliability and scalability of the solution

For each case study, responses should include:

• the client organisation
• the installation date
• the number of service users or devices supported
• any differences between the solution in the case study and the one detailed in their response

If case studies cannot be provided, for example because the supplier or alarm equipment is new to the market, bidders should describe how they will demonstrate functionality and interoperability through testing.

The testing should:

• use the same ARC solution proposed for the service
• take place in an operational environment (instead of relying solely on standards compliance or lab-based testing)

Where possible, commissioners should make sure this testing is complete before awarding the contract.

7.2. Elements in development

If a bidder’s proposed solution contains any elements that are still in development or testing before being used in an operational environment, their response should include:

• details of the elements
• timescales for the development or testing to be completed and the elements entering the production release

Evaluation guidelines

Bidders’ responses should either detail elements that are still in development or testing, or state that there are no such elements.

Responses to the second part of the requirement will provide details of the expected timescales for any development and testing work to be completed.

Commissioners should establish if any elements of the solution that are still in development or testing are important requirements. If they are, there is a risk that the element will not be provided, or will not be provided as described. It could also mean the whole solution is delayed.