Guidance

Digital telecare commissioning guidelines: alarm receiving centre solutions

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 the alarm receiving centre (ARC) solution 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 a digital ARC solution. ARC refers to the technology solution that receives calls from telecare alarms. Call handlers use the ARC solution to answer alarm calls and arrange a suitable response, where required.

The requirements assume that commissioners are procuring a software as a service (or cloud-based) solution, not an on-premise solution (where the ARC equipment is on the provider’s premises).

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.

This guidance only relates to the technical requirements for the ARC solution. If commissioners are also looking for call handling resources (staff answering calls using the ARC solution), they should add separate requirements for this.

The requirements relate to functionality similar to that offered by existing analogue solutions. Some digital ARCs provide additional functionality, such as monitoring of activities of daily living sensors, proactive monitoring, and integration with smart consumer and health 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, for example alarm IP communication protocol (PD CLC/TS 50134-9) and NOW-IP (BS 8521-2:2020).

In some cases, suppliers’ implementation approaches differ from the published standard, or the standard is vague allowing for different interpretations. Both can cause issues. Examples include:

• different interpretations of standards can cause interoperability issues between alarms and ARCs so that each mix of solutions and equipment must be configured and tested individually, increasing the time, effort and risk of installation
• relying on using virtual private networks (VPNs) and mobile network private access point names (APNs) to provide a secure connection makes it more difficult to add an alarm to an ARC and to move between ARCs
• use of VPNs or APNs makes it more difficult to set up fixed broadband connectivity, which limits resilience options

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

1.1. Alarm IP communication protocol and NOW-IP standards

The ARC solution should support the alarm IP communication protocol (PD CLC/TS 50134-9) and NOW-IP standards in full.

Bidders should confirm that their ARC solution meets the documented standards in full.

If variants have been implemented, the bidder should provide details. This includes where the ARC solution has implemented variants to work with older alarm devices that do not use the documented standard.

Evaluation guidelines

Bidders should confirm that their ARC solution meets the standards in full. This should be the documented standard as published by the British Standards Institute (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 ARC solution meets the BSI standards, meaning that 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.

Given that many of the alarm devices and grouped housing solutions currently on the market use variants of the standards, it is likely that the ARC solution will also have implemented these to provide support for these older devices.

The ARC should support the full documented standards. However, it’s likely that commissioners will also need the ARC to support variants to ensure backwards compatibility with older equipment. These variants should only be supported in addition to the full documented standard.

2. Connectivity requirements

To ensure future-proof and resilient connectivity, ARC solutions should support alarms that use internet-based connectivity and associated encryption.

VPNs and dial-up phone calls (session initiation protocol (SIP) lines) should only be used for resilience and backwards compatibility as they limit interoperability and make it more difficult to move between ARC solutions.

2.1. Internet connection for signalling and voice

The ARC solution should use a resilient internet connection for both signalling and voice.

Phone lines may also be supported, but only for service resilience and backwards compatibility with alarm devices that use dial-up voice.

Any phone lines used should be digital (SIP) lines.

Bidders should provide details of:

• the support their ARC solution offers for encrypted signalling and voice over a fixed broadband connection
• any use of phone lines for backwards compatibility or resilience purposes

Evaluation guidelines

The ARC solution should use fixed broadband connectivity for both voice and signalling (with encryption).

Solutions that can only support voice using a dial-up phone call are unacceptable.

The ARC solution will have to support dial-up for:

• backwards compatibility with alarm devices that use dial-up calls for speech
• failover to analogue protocols if a fault means digital calls cannot be made

This should be in addition to, not instead of, internet signalling and voice.

Any phone lines should be digital (SIP) lines. SIP lines will be the only option after January 2027, when integrated services digital network (ISDN) and analogue lines are withdrawn. Pre-digital phone line (PDPL) is not available as a replacement for ISDN.

2.2. TLS and SRTP encryption

Bidders should confirm the ARC solution uses transport layer security (TLS) and secure real time protocol (SRTP) encryption to secure the end-to-end connection to alarm and grouped living scheme devices for both signalling and voice.

Private APN and VPN connections may also be supported, but for backwards compatibility purposes only.

Evaluation guidelines

To ensure solutions are secure and to reduce the risk of data loss, bidders should confirm that their ARC solution uses TLS (version 1.2 or above), SRTP and AES-128 encryption as defined in the alarm IP communication protocol standard (PD CLC/TS 50134-9). Both TLS and SRTP are used on almost all websites and internet-based applications.

Private APN and VPN encryption may be offered to ensure the ARC solution has backwards compatibility with alarm devices that use this form of security. This should be offered in addition to TLS.

SRTP should be supported as a way to send voice as this ensures support for voice over internet protocol (VoIP) over fixed broadband connections, which adds resilience.

2.3. Outgoing calls

The ARC solution should be able to make outgoing calls to grouped living solutions and personal alarm devices over the internet connection (if the alarms support this).

Bidders should confirm their solution can make outgoing calls over the internet to alarm devices and grouped scheme equipment (where supported by the alarm or scheme).

Bidders should give details of any limitations on the type of outgoing call that can be supported.

Evaluation guidelines

Commissioners should include this requirement if they need their grouped living or personal alarm solutions to accept incoming calls from the ARC.

Responses should confirm that outgoing calls can be made on an internet connection and that a phone line is not needed for this.

Any limitations on the type of call that can be supported should be evaluated to ensure they meet the commissioner’s requirements.

3. Service management and service levels

Digital ARC solutions are complex to manage as they need regular updates to ensure they remain secure and to add new functionality.

In addition, the arrangements for monitoring and managing the ARC need to reflect that it is provided as software as a service. This means suppliers must use well-established IT industry service management processes, the most widely used being Information Technology Infrastructure Library (ITIL). These processes will also ensure that:

• suppliers better manage the digital solution to meet agreed service levels
• providers have better visibility of service issues, and the plans and timescales for resolving them

The requirements in this section aim to:

• clarify the service management tasks that the supplier is responsible for
• define service availability levels to ensure the ARC solution is reliable enough for safety-critical telecare

To make the telecare service fully resilient, providers also need to have in place business continuity and disaster recovery arrangements to handle calls and provide responses if an adverse event occurs. These arrangements are outside the scope of this document and commissioners will need to develop them separately.

3.1. Service availability levels

The bidder should provide guaranteed service levels, including service availability and fault fix times for the ARC solution.

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

Fault fix times should be measured from when the supplier or provider logs the fault to the time the provider accepts it as resolved. Faults that affect the service should be fixed within 4 hours.

These service levels should include all elements the supplier is responsible for and that are required for the ARC solution to operate, including the platform, software and associated connectivity.

Bidders must give details of the service levels that will be provided including:

• percentage solution availability
• fault fix times

Bidders should also provide details of how availability and fault fix times are defined (that is, what constitutes a fault) and how they are measured.

Evaluation guidelines

Bidders should provide details of their availability and fix time service levels.

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.76 hours of downtime a year. This is common in the IT industry and should be achievable for solutions with resilience.

It is also suggested that faults that affect the service should be fixed within 4 hours.

These figures exceed those defined in other guidance but are 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 and fix times in this requirement.

Downtime in hours per 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.

The service levels should include:

• all elements of the ARC solution
• any associated services (for example, softphones, which use VoIP technology to connect users to call-handling staff using the internet)
• the connectivity required to enable the solution to operate

Any exclusions should be assessed to see how they would affect operations.

Responses should provide a clear definition of what constitutes a fault and how this relates to the availability level and fault fix time. If the definition is unclear, it is unlikely to be measurable or enforceable in practice.

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

3.2. Technical arrangements

Bidders should provide details of the technical arrangements used to ensure that the service levels are met. The response should include details of:

• the compute or server arrangements, including for any third-party services or solutions used
• hosting arrangements
• connectivity

Evaluation guidelines

The purpose of this question is to ensure that bidders have appropriate technical arrangements in place to deliver the stated service levels.

Bidders should show that:

• they have 2 infrastructures or services available - primary and standby
• they’re using hosting arrangements that offer the level of power, uninterruptable power supply, cooling and security required to support a resilient solution
• they have at least 2 independent internet connections serving the data centre that hosts the solution

3.3. Backup systems

Bidders should provide details of the business continuity arrangements used to ensure the ARC solution and any other required solution elements remain available at all times.

Responses should include details of:

• any backup system or alternative arrangements used to rapidly provide a replacement for the ARC solution and any other required solution elements if the primary systems fail
• 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 starts it
• whether alarm calls can continue to be received and responded to in the period between the primary system failing and the backup system becoming fully available

Evaluation guidelines

Bidders should demonstrate that they will be able to quickly establish a replacement ARC solution or service if the primary solution 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 provider data, such as configurations, user details, call records, historical status logs and so on. Bidders should provide details of how long it will take to restore the data onto a backup system.

Data generated between backups may be lost if the system fails. This means that the frequency of backups should be defined by how much and what sort of data the commissioner is willing to lose. A solution that uses a mirrored architecture can prevent almost all data loss, but this may increase costs. One or 2 hours between backups may be acceptable for some commissioners.

When evaluating the timescales for making the backup systems available, commissioners should consider whether or not alarm calls can be received and responded to if the primary system fails. Shorter restore timescales are likely to be needed if alarms cannot be used until the backup system is working and data has been restored.

3.4. Proactive monitoring

Where a fault impacts the ARC solution, the supplier should provide proactive and provider specific information on the fault and its impact.

Information should come from the supplier directly. The provider should not need to ask a third-party supplier 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 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 third-party supplier to obtain information.

The information on the fault should be provider-specific, detailing how the solution is affected and what it means for services. For example: “There has been a VPN failure, this means alarms that use connectivity from network provider XX cannot make alarm calls although they will appear online on the device management platform (DMP).” It should not be a generic update like: “There has been a failure of our VPN connection.”

3.5. Service management arrangements

The bidder should have service management arrangements in place to monitor the operation and performance of their solution and to manage faults.

Bidders should provide details of the service management processes used to monitor and report on solution performance and manage faults.

Evaluation guidelines

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

3.6. 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 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 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 resolving the issues. For high-impact faults (potentially affecting large numbers of alarm devices), hourly updates should be expected.

3.7. 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
• 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.8. 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 ARC solutions need regular updates to:

• keep them 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

The move to digital means ARC solutions 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 the security of user data and the solution is not compromised.

Data security is a particular risk for ARC solutions (more than for alarm devices and grouped living solutions) since they can process and store significant amounts of personally identifiable and sensitive information.

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 that bidders must meet.

4.1. Cyber security accreditation

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

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

The accreditation should cover the full scope of the solution 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 solution 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 validate that it provides like-for-like protections to ISO27001, Cyber Essentials or Cyber Essentials Plus.

ISO27001 (or an equivalent standard) is the preferred certification for ARC because of the nature of the data it processes. The commissioner’s DPIA will determine whether this is a mandatory requirement or a preference.

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 demonstrate that 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 address each of the defined elements and include timescales for:

• detection
• completing the key 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. Penetration testing

The ARC solution, including any subcontracted elements, 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.

Penetration tests should also be provided for any elements of the solution that have been subcontracted to another supplier (for example, softphones).

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 the ARC solution remains secure after any software updates or configuration changes.

4.5. Data protection

Bidders should provide details of how their solution and any subcontracted elements meet the requirements of the Data Protection Act 2018 (DPA) and the General Data Protection Regulation (GDPR). This includes subject access requests, right to be forgotten and so on.

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

Evaluation guidelines

Bidders should show compliance with DPA and GDPR, including subject access requests, right to be forgotten and so on.

The response should address the whole solution, including any subcontracted elements.

Responses should include the recording of calls as these could include sensitive discussions, like 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.6. Backup systems

Bidders should provide details of the business continuity and disaster recovery arrangements in place to ensure their solution and the associated support arrangements can be quickly restored if the primary system fails.

Examples include:

• service desk
• support teams
• software development staff

If any elements of the solution are subcontracted, bidders should also give details of the subcontractors’ arrangements.

Evaluation guidelines

Bidders should show that they will be able to quickly restore services, data, and support and management processes following a disaster.

This question is asking for information on wider business continuity arrangements, such as ensuring supplier staff can continue to work. (Requirement 3.2 focuses on the technical arrangements.)

Bidders should also provide details for subcontractors.

5. Data standards requirements

ARC solutions contain significant amounts of data on service users, connected equipment and calls. To future-proof the ARC solution, this data should be easily accessible to support:

• better reporting and visualisation
• data analytics
• integration with other health and social care systems

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. Exporting data

The ARC solution should provide full access to all the provider data it stores.

As a minimum, the solution should offer the provider 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 their status
• telecare service user data
• historical data relating to alarm calls, reasons and responses
• background calls and messages - these relate to user or alarm activity and are logged by the ARC solution without needing a call handler
• call recordings
• failed alarm connections

Bidders should provide details of:

• how they provide access to data
• what format the data is in
• what data fields are available
• which data fields cannot be exported (if any)

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 give full reporting capability.

5.2. API offering

The solution should offer an API to allow other systems to access and update (where applicable) user, alarm, call 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 enough to give integration capability.

6. Provider obligations requirements

Digital telecare solutions are likely to use technology provided by several organisations. For example, a digital ARC solution may use the provider’s client devices and authentication, while the supplier is responsible for the application, softphones and so on.

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, softphones or other telephony services)
• in-building cabling
• cyber security
• user 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 details 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

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 issues

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 solution is new to the market, bidders should describe how they will demonstrate functionality and interoperability through testing.

The testing should take place:

• with the same alarm devices and digital protocols used by the provider
• in an operational environment (rather than 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.