Adult Social Care

Personalisation Portal Management System

ITT SCHEDULE 1

Statement of Requirements

TABLE OF CONTENTS

1.0.Introduction

1.1. Profile of the Local Authority

1.2. Strategy & Environment

1.3. Background to Personalisation in Darlington

1.4. Confidentiality

1.5. Assessment of Quality of Tender

1.6. Costs of Goods and Services

2.0.System and Functionality Requirements

2.1. Statement of Requirements - Checklist

2.2. General System Requirements (Functionality)

2.3. Overall Software Design

2.4. User Interface

2.5. Search Facilities (Internal Council Use ONLY)

2.6. Management Reporting

3.0.Personalisation (Functionality)

3.1. Personalisation General

3.2. Personalisation Web Portal

3.3. Adult Safeguarding

3.4. Finance

3.5. System Administration

3.6. Records Management

4.0.Interfaces (Functionality)

4.1. Interfaces

5.0.Audit, Control & Security (Functionality)

5.1. Audit

5.2.Control of Access

5.3. Security of Data

6.0.Legislative Requirements (Functionality)

6.1. Legislative Requirements & Other Issues

7.0.Levels of Service (Functionality)

7.1. General Levels of Service

7.2. Systems Performance and Testing

7.3. Printing

7.4. System Storage & Transactional Volume

7.5. Resilience and Backup

7.6. Systems Support and Maintenance

7.7. Code of Connection for Third Party Application Vendors

7.8. Training

7.9. Future Upgrades

8.0.Risk Management (Methodology)

8.1. Risk Management

9.0.Product Development (Methodology)

9.1. Product Development

10.0.Project Management (Methodology)

10.1. Project Management

11.0.Implementation Specification (Methodology)

11.1. Implementation Specification

12.0.Exit Strategy (Methodology)

12.1. Exit Strategy

13.0.Business Continuity Plans (Methodology)

13.1. Business Continuity Plans

14.0.Cost Breakdown (Value for Money)

14.1 Procurement Costs Breakdown

14.2 Optional Costs Breakdown

Appendix A

1.0.Introduction

Darlington Borough Council has invited applications from suppliers who wish to be considered for selection to tender for the provision of an Adult Social Care Personalisation Web Portal Management System to support developments being made through our Transforming Adult Social Care Programme.

This document contains information covering the profile of the Authority, its Adult Social Care environment and a brief outline of the Authority’s current system and its support, together with an indication of the objectives of this project and a proposed implementation timetable.

1.1. Profile of the Local Authority

Darlington Borough Council is a Unitary Authority that provides an extensive range of services for over 100,000 people in the area and employs over 5,000 people.

The full range of functions within Darlington Borough Council is carried out via four main Departments.

These are:

-Chief Executive’s

-Community Services

-Corporate Services

-Children’s Services

Adult Social Care sits within Community Services and has approximately 400 Council officers.

1.2. Strategy & Environment

CareFirst is the primary recording system used across all of Adult Social Care. This includes Community Care, Learning Disabilities and Mental Health. The primary modules currently in use are: My Care First; Care Base; Care Assess; Care Pay. CareFirst is also used in Children’s Services and some areas of the local PCT. We currently have around 700 users.

The introduction of mobile technology is currently being implemented and is at pilot stage. Mobile technology will be used when possible in line with the developing corporate strategies.

An opportunity has arisen to look at enhancing the Adult Social Caremanagement system capability.The focus being around giving the citizens of Darlingtonthe option of choosing toself directtheir own support. This follows the agreement within the 2007 Government concordat Putting People First (

There are four keys elements to Putting People First:-

  • Access to Universal Services
  • A focus on Prevention and Early Intervention
  • MaximisingChoice and Control
  • Making better use of Social Capital

Our strategy focuses around improving access to universal services information, the ability to self assess on-line, the ability to create a support plan by having increased access to support providers, easy and quick monitoring of personal budgets, etc.

1.3. Background to Personalisation in Darlington

The Government has set out its vision for the future direction of social care through a number of key policy documents, notably “Putting People First” 2007 and “Our Health Our Care Our Say” 2006. A key theme of this vision is the idea that people should have the information and support they need to have as much choice and control over how they receive support, this is often called personalisation.

Changing the way people are supported now to a more personalised way, will mean over time there will be a transfer of power from organisations to individuals. It will also mean that there will be a big change in the way that the Local Authority and providers do business. It will mean that in the future there will be more and more individually tailored and co produced ways of meeting social care needs.

The challenge to Darlington Council and its partners is to transform its current model of social care to one that is driven by people directing their own support to meet their own identified social care outcomes. This transformation is not simply about changing how we do things it is also about how we think about social care and how it is delivered.

The transformation of adult social care to a model that makes sure that it improves the outcomes for the people of Darlington is a challenging one. To ensure that change happens we have developed a transformation programme that has organised what needs to be done into seven broad work streams:

1.Supporting the Market

2.Communications and Workforce Development

3.Access, Information & Support

4.Systems & Process’s

5.Self Directed Support

6. Partnership & Prevention

7.Provider Services

1.4. Confidentiality

This document is copyright and will remain the property of Darlington Borough Council. The contents of this document and any correspondence documents are confidential.

1.5. Assessment of Quality of Tender

The vendor will act as Prime Contractor and take full responsibility for all third parties providing software or services included in the contract.

The vendor must provide responds to and substantive comments on the various requirements/informationrequestedin Section 2 toSection 14.

1.6. Costs of Goods and Services

The vendor is asked to provide a breakdown of procurement costs as per Section 14.1. The procurement costs will be used to evaluate the cost element of the tender. The vendor is also asked to provide where possible the optional costs as per Section 14.2. The optional costs will not form part of the tender evaluation.

A separate Microsoft Excel spreadsheet, named

ITT Schedule3 Appendix2 ITT PricingSchedule v1.1.xls has been provided to allow the cost information to be entered electronically.

2.0.System and Functionality Requirements

In order to ensure that Adult Social Care continues to improve their services, the software to be purchased must be able to allow:-:

  • Individuals to self direct their own support (by providing an on-line supported self assessment questionnaire, personal budget calculator, support planning tools, etc)
  • The entering and viewing of data quickly and easily
  • The collection and processingof data from the system
  • An integrated solution with our existing adult case management system (including specifically admin and finance)
  • The production ofcomprehensive management information and provide bespoke reports through an appropriate reporting tool e.g. Business Objects.
  • Support the national guidelines on ESCR (Electronic Social Care Record) for adults.
  • Managed access by other authorised agencies and service providers.
  • The system to be compatible with mobile working

A more detailed breakdown of the requirements and functionality required from the software is set out in the Statement of Requirements Checklist below.

2.1. Statement of Requirements - Checklist

The Statement of Requirements Checklist must be completed in full and returned, together with completed Sections 6 to 11 plus supporting documentation.

The formatting of this document MUST not be changed

Vendors must indicate the following in their responses to specific system requirements:

  • “A” – Included as standard in the product
  • “B” – Not currently included as standard but is a planned enhancement to the system
  • “C” – Not included as standard but can be included as a bespoke amendment at no additional cost
  • “D” – Not included as standard. It should be possible to tailor the system to meet this level of functionality subject to further investigation and costing.
  • “E” – The software does not meet this requirement.

Notes:

-Where a requirement has several elements the Vendor must give a response to each element.

-Vendors are required to substantiate their rating, for example by details of how the requirement will be achieved or by providing expected release dates of enhancements.

ITT Schedule1 – Specification (Statement of Requirements) v1.8.doc

17/11/2018

Page 1 of 57

2.2. General SystemRequirements (Functionality)

2.3. Overall Software Design
Overview:
Ref / Requirement / Source
Refs / A-E / Tender Response
2.3.1 / Provide appropriate facilities to support the business processes as described in the Background Information (in Sections 1 and 2).
2.3.2 / Full interoperability and integration of software in accordance with e-government interoperability framework (e-gif) requirements:
  • Providing a browser interface for access
  • Using XML as the primary means for data integration
  • Using Internet and World Wide Web standards ( standards)
  • Using metadata for content management

2.3.3 / Design to facilitate implementation, easy upgrades and modifications.
2.4. User Interface
Overview:
Ref / Requirement / Source
Refs / A-E / Tender Response
2.4.1 / Consistency through the software relating to:
  • Keyboard shortcuts

  • Menu structures and terminology

  • Colour coding of fields or other areas of the screen

  • Screen layout – suitable for screen resolutions (RNIB spec) and work with different/wide range of web browsers (including web portal front end)

  • Ability to move and resize viewing windows

  • The ability to pause and later resume processes whilst moving around other screens or systems

2.4.2 / The system should provide:
  • Undo facility

  • User defined mandatory fields

  • Utilisation of descriptive and intuitive field names rather than codes or abbreviations

  • Notepad facilities

2.4.3 / The on-line help/documentation facility shall:
  • Be accessible from any screen

  • Be context sensitive dependent on the screen or function currently being accessed

  • Allow customised content specific to the users to be added

  • All documentation should be clearly written with minimal use of technical terminology and should be updated in parallel with any changes to the system.

  • Be available to field level on each screen

2.4.4 / Warning and error message facilities:-
  • Warning messages, further action permitted

  • Warning and error messages must be written in plain English with a description of what action should be taken by the user

  • Error messages should inhibit further action

2.4.5 / The user interface must be simple with well organised information.
2.4.6 / Data entry should be wizard led to enable clear, standardised entry of information.
2.4.7 / Familiar look and feel: The system should mirror the look and feel of a paper document as far as possible (using consistent layout, colour, etc).
2.4.8 / All information relating to a single form should be available on a single screen (could be scrollable if necessary)
2.4.9 / All screens must be navigable within no more than 3 clicks of each other.
2.4.10 / The system must support the use of user defined fields.
2.4.11 / The system must provide pick lists for fields that have limited choices.
2.4.12 / It must be possible to maintain (add, amend, delete from) pick lists locally without affecting historical records.
2.4.13 / Allow pick lists to be exported without having to create a local report.
2.4.14 / Facility to link pick lists where appropriate (for example outcome and outcome reason). The value displayed in the linked pick list will be dependent on the value selected in the primary pick list.
2.4.15 / It must be possible to assign common tasks to function buttons.
2.4.16 / All previous screens must be easily accessible.
2.4.17 / The home screen must be accessible from all screens.
2.4.18 / Where colour is used on the screens, it should be suitable for users who are colour blind or visually impaired
2.4.19 / It should be possible to zoom in or resize a screen to aid users who are visually impaired.
2.5. Search Facilities (Internal Council Use ONLY)
Overview:
Ref / Requirement / Source
Refs / A-E / Tender Response
2.5.1 / Include comprehensive search facilities easily accessible from any screen.
2.5.2 / Display all records that match the criteria set by the user with a facility to re-define the criteria to further reduce the selected records.
2.5.3 / Display search results in an order selected by the user and with sufficient information to allow easy identification of the record found.
2.5.4 / Ability to drill down into each search result, accessing the record via the appropriate screen.
2.5.5 / Allow a search to be limited to a specified user or team.
2.5.6 / Search facilities must include the following: client name, ID, NI number, address, date of birth,
building, organisation or organisation ref
2.5.7 / The system must perform a search before allowing a new client record to be created.
2.6. Management Reporting
Overview:
Ref / Requirement / Source
Refs / A-E / Tender Response
2.6.1 / Provide plain English management reports on any range of operational information.
2.6.2 / Provide a range of statistical information in reports as part of the standard system package.
2.6.3 / Provide on-line management information without the need to run reports.
2.6.4 / Provide fully comprehensive ad hoc reporting tools for users to easily create non-standard reports. These should include the following functionality:-
  • Built-in support and configuration for the full database structure for effective reporting on any field or other element of the database

  • Easy to use report production facility

  • Ability to create complex reports with minimal knowledge of query languages or other development environments

  • On-screen output facility for quick display of reports

  • Tabling and charting facilities allowing reports to be analysed and presented visually

  • Drill-down facilities for the on-screen review of raw data

  • Validation rules incorporated into the report writing tool to minimise errors

2.6.5 / Ability to edit standard reports with the ad hoc reporting facility whilst protecting the original from corruption.
2.6.6 / The system must have standard reports for government statutory returns including but not limited to:-
  • All DH (Department of Health) statutory returns.

  • CLG (Communities and Local Government) returns

  • National Indicator set

  • RAP return

  • PAF (Performance Assessment Framework) indicators

  • CRILL (Capturing Regulatory Information at Local Level)

  • Adult Social Care Combined Activity

  • PPSEX01 return

2.6.7 / For each summary or statistical report, the system must provide a breakdown report showing the individual details that make up the summary report.
2.6.8 / The source code of all standard reports must be available to view.
2.6.9 / User created reports must be available to run through the system by designated users.
2.6.10 / Provide standard exception reports to identify missing key information.
2.6.11 / Provide standard exception reports to identify duplicates
2.6.12 / A data schema or dictionary must be provided to describe the database.
2.6.13 / Access to the data schema must be available from the report writer.
2.6.14 / The system must allow the creation of views or subsets of data.
2.6.15 / The system must provide run-time estimates for any query or report.
2.6.16 / The system must allow reports to be output in standard MS office format (e.g. word, excel)
2.6.17 / The system must allow reports to be output in PDF format.
2.6.18 / The system must include an integrated report writer without the need for additional software or licences.
2.6.19 / The report writer must utilise a recognised standard query language such as SQL.

3.0.Personalisation (Functionality)

3.1. PersonalisationGeneral
Overview:
Ref / Requirement / Source
Refs / A-E / Tender Response
3.1.1 / Facility to look up addresses based on but not limited to addresses on the local gazetteer or alternatives.
3.1.2 / The system must incorporate an address matching facility whereby addresses on the system can be matched against a pre-defined extract file.
3.1.3 / Validation of data must include rejecting values that are infeasible (e.g. dates of birth in the far future or far past; end dates that occur before start dates)
3.1.4 / Avoid the duplication wherever possible.
3.1.5 / Facility to link scanned and other electronic documents to cases.
3.1.6 / Facility to link to standard documents and leaflets.
3.1.7 / The system must be able to set up hyperlinks to useful web pages.
3.1.8 / The system must provide a function to merge records that are identified as duplicates into a single record.
3.1.9 / The system must support the principles of the developing adult CAF agenda.
3.1.10 / Flexibility of structure to allow centralised or devolved working and with the facility to amend the structure in the event of organisational changes.
3.1.11 / The system must allow digital signatures to be captured and utilised on documents.
3.1.12 / It must be possible to link a document to more than one person or case.
3.1.13 / It must be simple to identify multiple people associated with a single document.
3.2. Personalisation Web Portal
Overview:
Ref / Requirement / Source
Refs / A-E / Tender Response
3.2.1 / The system must record the basic details, including but not limited to:
  • Client name
  • Address (including postcode)
  • Date of birth
  • NI number
  • NHS number
  • Personal details (ethnic origin, gender, religion etc.),
  • Telephone number,
  • Carer details
  • details of client’s relatives,
  • details of professionals involved in the case,
  • doctor’s name and surgery,
  • hospital details,
  • housing type,
  • housing tenure,
  • medical details (including any medical conditions or disabilities),
  • referral details,
  • outcomes,
  • assessment details,
  • client needs,
  • care plan / support plan details.

3.2.2 / The system must allow any specialist assessments (e.g. occupational therapy assessment)to be uploaded and saved on client portal
3.2.3 / The system must allow the client the ability to contact adult social care, by allowing them access to appropriate emergency channels
3.2.4 / The system must be able to identify whether anyassessments were completed by the individual, a family member, carer, provider (including name), adult social services or other
3.2.5 / Incorporate workflow which can be tailored to local working practices.
3.2.6 / All assessments made on the web portal must allow easy methods to forward to the council