ITT Standard Sections - WhatDoTheyKnow€¦ · Web viewRefs A-E Tender Response 9.1.1 The Vendor...

Adult Social Care

Personalisation Portal Management System

ITT SCHEDULE 1

Statement of Requirements

ITT Schedule1 – Specification (Statement of Requirements) v1.8.doc26/05/2023

TABLE OF CONTENTS

1.0. Introduction.............................................................................................41.1. Profile of the Local Authority..............................................................41.2. Strategy & Environment.....................................................................41.3. Background to Personalisation in Darlington......................................51.4. Confidentiality.....................................................................................61.5. Assessment of Quality of Tender.......................................................61.6. Costs of Goods and Services.............................................................6

2.0. System and Functionality Requirements..............................................72.1. Statement of Requirements - Checklist..............................................82.2. General System Requirements (Functionality)...................................92.3. Overall Software Design.....................................................................92.4. User Interface...................................................................................102.5. Search Facilities (Internal Council Use ONLY).................................132.6. Management Reporting....................................................................14

3.0. Personalisation (Functionality)............................................................183.1. Personalisation General...................................................................183.2. Personalisation Web Portal..............................................................193.3. Adult Safeguarding...........................................................................263.4. Finance.............................................................................................273.5. System Administration......................................................................293.6. Records Management......................................................................30

4.0. Interfaces (Functionality)......................................................................324.1. Interfaces..........................................................................................32

5.0. Audit, Control & Security (Functionality)............................................335.1. Audit.................................................................................................335.2.Control of Access..............................................................................345.3. Security of Data................................................................................37

6.0. Legislative Requirements (Functionality)...........................................386.1. Legislative Requirements & Other Issues........................................38

7.0. Levels of Service (Functionality).........................................................407.1. General Levels of Service................................................................407.2. Systems Performance and Testing..................................................417.3. Printing.............................................................................................417.4. System Storage & Transactional Volume.........................................427.5. Resilience and Backup.....................................................................447.6. Systems Support and Maintenance..................................................457.7. Code of Connection for Third Party Application Vendors.................467.8. Training............................................................................................467.9. Future Upgrades..............................................................................47

8.0. Risk Management (Methodology)........................................................488.1. Risk Management............................................................................48

9.0. Product Development (Methodology)..................................................499.1. Product Development.......................................................................49

10.0. Project Management (Methodology)............................................4910.1. Project Management......................................................................49

11.0. Implementation Specification (Methodology)..............................51ITT Schedule1 – Specification (Statement of Requirements) v1.8.doc26/05/2023

Page 2 of 58

11.1. Implementation Specification..........................................................51

12.0. Exit Strategy (Methodology)..........................................................5312.1. Exit Strategy...................................................................................53

13.0. Business Continuity Plans (Methodology)..................................5413.1. Business Continuity Plans..............................................................54

14.0. Cost Breakdown (Value for Money)..............................................5414.1 Procurement Costs Breakdown.......................................................5414.2 Optional Costs Breakdown..............................................................56

Appendix A....................................................................................................57


Page 3 of 58

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 Care management system capability. The focus being around giving the citizens of Darlington the option of choosing to self direct their own support. This follows ITT Schedule1 – Specification (Statement of Requirements) v1.8.doc26/05/2023

Page 4 of 58

the agreement within the 2007 Government concordat Putting People First (http://www.cpa.org.uk/cpa/putting_people_first.pdf).

There are four keys elements to Putting People First:- Access to Universal Services A focus on Prevention and Early Intervention Maximising Choice 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 Market2. Communications and Workforce Development3. Access, Information & Support4. Systems & Process’s5. Self Directed Support6. Partnership & Prevention7. Provider Services


Page 5 of 58

http://www.cpa.org.uk/cpa/putting_people_first.pdf

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/information requested in Section 2 to Section 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 Pricing Schedule v1.1.xls has been provided to allow the cost information to be entered electronically.


Page 6 of 58

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 processing of data from the system An integrated solution with our existing adult case management

system (including specifically admin and finance) The production of comprehensive 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.


Page 7 of 58

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.


Page 8 of 58

2.2. General System Requirements (Functionality)

2.3. Overall Software DesignOverview:

Ref RequirementSourceRefs 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 (www.w3c.org standards)

Using metadata for content management

2.3.3 Design to facilitate implementation, easy upgrades and modifications.


http://www.w3c.org/

2.4. User InterfaceOverview:


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 facilities2.4.3 The on-line help/documentation facility

shall: Be accessible from any screen


Page 10 of 58

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


Page 11 of 58

(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.


Page 12 of 58

2.5. Search Facilities (Internal Council Use ONLY)Overview:


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.


Page 13 of 58

2.6. Management ReportingOverview:


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


Page 14 of 58



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,


Page 15 of 58



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


Page 16 of 58



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.


Page 17 of 58

3.0. Personalisation (Functionality)

3.1. Personalisation General Overview:


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


Page 18 of 58

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 PortalOverview:


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,


Page 19 of 58

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 any assessments 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

3.2.7 The system must indicate if consent to share information has been given.

3.2.8 It must be possible to inhibit the display


Page 20 of 58

or print of information where consent to share information has not been given.

3.2.9 The system must be compatible with the national standards for SAP (Single Assessment Process).

3.2.10 The system must allow a matching process to local service providers based on client care needs, where this information is requested.

3.2.11 A team manager must be able to view all cases for their team.

3.2.12 A team manager must be able to view all cases on the web portal for a selected team member.

3.2.13 The system must incorporate case task lists for individual workers.

3.2.14 The system must allow team managers to access the case task lists of their team members.

3.2.15 The system must calculate the cost details of a care plan / support plan.

3.2.16 The system must produce a formatted printout of the care plan / support plan including costs.

3.2.17 It must be possible to print out details of the client supported self assessment and any support plans

3.2.18 The system must allow historical information to be held on clients

3.2.19 The system must allow service reviews to be set.


Page 21 of 58

3.2.20 There must be a facility to set up an interim support plan.

3.2.21 There must be a facility to suspend / reactivate an assessment with a reason why. The time during which an assessment is suspended should not be included in the performance indicator reports

3.2.22 The system must allow the assessment or self-assessment (supported or otherwise) to be authorised by an appropriate user.

3.2.23 The system must include a facility to enter an estimated date of birth if the actual date of birth is not known. The date of birth must be clearly identified as an estimated value.

3.2.24 It must be possible to add retrospective items to the support plan.

3.2.25 It must be possible to record the source of the referral on the system. (e.g. hospital, first contact, internal, self-assessment)

3.2.26 It must be possible to set up a referral using the details of an historical referral (e.g. to enter a re-referral)

3.2.27 The system must clearly indicate who is the allocated worker for each case

3.2.28 The system must ensure each case worker is associated with a manager.

3.2.29 Time periods must be measured in standard units throughout the system.


Page 22 of 58

3.2.30 It must be possible to allocate a case to another team member or team and retain a history of who has been involved with a case through its lifespan.

3.2.31 When a case is closed, all activities associated with the case should also be closed.

3.2.32 The system must flag if a visually impaired client or hearing impaired client is on the visually impaired register or hearing impaired register or holds a CVI certificate.

3.2.33 The system must provide email notification of referrals and actions due.

3.2.34 Functionality to reduce the possibility of creating duplicate person records through automated checking when creating a new record.

3.2.35 Professionals should only able to view and download assessments which they already have rights to access (For example: a carer assessment may go to GHF for carer’s card, but we would not necessarily want them to be able to view every record in the system).

3.2.36 The system must be able to identify the type of housing of a client (e.g. private sector, housing association, TRISTAR (council housing), owner occupier).

3.2.37 The system must be compliant with statutory ESCR guidelines

3.2.38 The system must hold a risk assessment


Page 23 of 58

against a client.3.2.39 The system must allow for carer

assessments.3.2.40 The system must facilitate the setup of a

local points based system to reflect client needs and circumstances.

3.2.41 The system must provide flexibility in the way the outcomes of the personal budget calculator calculation are communicated to the client i.e. electronically or paper copy

3.2.42 The system must allow a personal budget to be set for each client and to record changes to allocations over a period of time (personal budgets may change based on changing needs)

3.2.43 Provide a point’s based assessment to be related to a personal budget for each client.

3.2.44 It must be possible for clients to view what support is provided and which organisations are responsible for those services via a web interface.

3.2.45 It must be possible for clients to search the service providers on the web by name, location type of support, locality

3.2.46 The self-assessment web form must capture the following as a minimum:-

Client details e.g. name, address, date of birth, tel, e-mail address, mobile, etc

Carer details


Page 24 of 58

Service needs Summary assessment details

3.2.47 It must be possible to create and tailor the web form to local needs e.g. supported self assessment, support plans, review, etc.

3.2.48 The self-assessment web form should utilise scripting to ensure all relevant information is captured with minimum redundancy of data entry. (e.g. If the answer to question A is yes then display the questions in section B otherwise display the questions in section C)

3.2.49 The system must allow specified low level equipment to be requested directly by the client through a self-assessment web form.

3.2.50 It must be possible to identify subsequent self-assessments within the system. Either updates, replacements or amendments (self assessment in more than one sitting).

3.2.51 Changes in client details made in subsequent self assessments (will need some validation) are automatically recognised and updated in the client record with a clear audit trail.

3.2.52 The system must allow the client to easily message the local authority e.g. to help liaise about an appointment

3.2.53 The system must be compatible with the national standards for SAP (Single


Page 25 of 58

Assessment Process).3.2.54 The system must allow matching to

service providers based on client care needs.

3.2.55 The system must allow the set up of ISO (Individual Service Orders).

3.2.56 ISO (Individual Services Orders) must indicate what services are required and for how long.

3.2.57 The system must provide alerts when targets deadlines are due.

3.2.58 All cases for a particular team should be passed to and allocated from a single repository by an authorised user (e.g. team leader). It must be possible to have multiple authorised users for a team to allow cover for holidays and sickness.

3.3. Adult Safeguarding Overview:


3.3.1 The system must support the principles of the national adult safeguarding program.

3.3.2 It must be possible to identify adult safeguarding referrals within the system.


Page 26 of 58


Page 27 of 58

3.4. Finance Overview:


3.4.1 The system must hold information required for financial assessments including:-

Client details, Client income, Capital, Allowable expenditure (e.g.

disability related expenditure) and other sources of funding such as Independent Living Fund (ILF)

3.4.2 The system must allow new income, capital or expenditure items to be added to the assessment form as required.

3.4.3 The system must calculate a client’s financial contribution towards care based on the details provided in the financial assessment.

3.4.4 The system must allow the gross amount due to be paid to the service provider and separate invoicing of the client for their contribution. The system must allow the option to pay net of the client contribution.

3.4.5 The system must allow scheduled reviews of financial assessments.


Page 28 of 58

3.4.6 The system must allow financial assessments for residential clients

3.4.7 The system must allow financial assessments for non-residential clients.

3.4.8 The system must fully integrate finance, case management and commissioning of services.

3.4.9 The system must be compliant with CRAG (charging for residential accommodation guide)

3.4.10 It must be possible to set up and change charges to reflect the local charging policy.

3.4.11 The system must be able to remove service charges from the system without affecting historical data.

3.4.12 The system must provide a web based financial assessment form for remote assessments or financial self-assessments.

3.4.13 Facility to allow global financial reassessments for example, when there are changes to statutory allowances or disregards

3.4.14 Facility to set rules regarding assessments (e.g. Disregard of home value for the first 12 weeks of care)


Page 29 of 58

3.5. System AdministrationOverview:


3.5.1 The system should allow the option of using active directory login as the system login.

3.5.2 The system should allow the option of changing the active directory login associated with the user.

3.5.3 Allow customisation of menus for different users.

3.5.4 Availability of standard user profiles to simplify the creation of new users and the ability to copy a standard profile to simplify the creation of new standards.

3.5.5 Allow a user to be assigned to more than one profile (inheriting all the permissions from each user group they are a part of)

3.5.6 Provide remote system access to facilitate home working.

3.5.7 Allow access to suitably authenticated external users. (e.g. service providers to update organisation and audit details, NHS partners)

3.5.8 The information available to external users should be strictly controlled from


Page 30 of 58

within the system (e.g. by the system administrator through user designation)

3.5.9 Ability to locally manage team and staff records (e.g. creation of new teams and movement of staff between teams)

3.5.10 Audited override facility for specified users (e.g. system administrator) to correct data.

3.5.11 Facility for specified users to remove a client and all associated records from the system. This facility must be restricted to authorised users and fully audited.

3.5.12 Facility for the system administrator to communicate an instant message from within the system to all current users.

3.6. Records ManagementOverview:


3.6.1 The system must calculate the date destroyed based on current guidelines (Currently 6 years after a case has been closed or 3 years after the client has deceased)

3.6.2 The system must provide notification when case documents are due to be examined for destruction.

3.6.3 The system must allow for a hard delete


Page 31 of 58

of all client case details from the system when a case is destroyed. Only summary client details (Name, DOB etc.) should remain to indicate that information was once held on the client (to fulfil FOI requests).

3.6.4 If a case is reopened in the system, the date to examine the file for destruction should be reset.

3.6.5 The system must provide a facility for managing documents including management of document storage.

3.6.6 Allow records to be flagged for archiving.3.6.7 Facility to archive all records flagged for

archiving.3.6.8 It must be possible to view archived

records within the system. 3.6.9 Archived records should not be included

in searches or reports on live data.3.6.10 Version control must be applied to

documents within the system.


Page 32 of 58

4.0. Interfaces (Functionality)

4.1. InterfacesOverview:


4.1.1 The solution must interface with the Council’s Agresso Financial management System for transfer of finance information and payment of invoices.

4.1.2 The solution must interface with Council’s CareFirst System for transfer of client information.

4.1.3 The solution must be linkable from the Councils website, with the solution capable of adopting the council’s website look and feel.

4.1.4 The solution must be accessible from the majority of standard web browsers (e.g. Internet Explorer, Firefox, Safari, etc). And from various version levels.

4.1.5 The various components proposed for the solution must fully integrate.


Page 33 of 58

5.0. Audit, Control & Security (Functionality)

5.1. AuditOverview:


5.1.1 The system must be able to produce audit logs to include, where applicable :-

user-id workstation id dates, times and details of key

events, e.g. log-on and log-off records of successful and rejected

system access attempts records of successful and rejected

data and other resource access attempts

changes to system configuration files accessed and kind of access alarms raised by the access

control system a before and after image of each

amendment History of user access to track

changes over time.

5.1.2 Audit data must be archival to audit to location at outside the database footprint

5.1.3 All history data must be: Marked to show when it was

changed


Page 34 of 58

Screen availability of the history must include the change information

5.1.4 Audit logs should be accessible on-line5.1.5 Where transactions backdate changes,

there must be no loss of the original audit trail. Vendors must describe how this is achieved.

5.1.6 The Audit Trail must be considered as data for reporting and archiving purposes.

5.1.7 Authorised users should be able to retain control over any default auditing actions and amend these where necessary.

5.2.Control of Access Overview:


5.2.1 The system should support role-based access control.

5.2.2 Security access control should be provided down to field level for individual users.

5.2.3 Data input screens should be customisable to reflect the level of security granted to the user, such that only admissible menu items, icons or windows are available.

5.2.4 Access controls must be based on


Page 35 of 58

unique user ids and passwords.5.2.5 Comprehensive password security and

management must be provided that includes, but is not limited to the following characteristics:-

Masked when input to the screen Encrypted when stored Minimum length of 7 characters

(Council has ability to choose parameters)

Conforming to the enhanced password structure of mandatory 3 out of 4 groups of characters being present i.e. upper case, lower case, numbers, special characters

Should keep a password history which prevents the re-use of the previous 12 passwords

Change interval of 30 days Ability to force users to change

temporary passwords at first log on

Allow the password to be changed at any time

5.2.6 The ability to change their own password to be given to each user.

5.2.7 The software must record incidents of failed access due to the use of invalid passwords.

5.2.8 An account should be suspended after a number of unsuccessful log-in attempts


Page 36 of 58

specified by the Council. A regular report is required for review by the System Administrator.

5.2.9 Ability to have password reminder e.g. asking questions e.g. mothers maiden name

5.2.10 Only the System Administrator must have the ability to:-

Re-enable suspended accounts Reset passwords Set-up user access to the

software Delete user access to the software Change rules relating to user

access5.2.11 Any software products used in

association with the main software must comply with the access criteria set for each user in the main software. The generation of users’ access profiles in the main software must be automatically replicated in any associated products and must not require separate user access profile set-up. (E.g. third party reporting tools where each user’s access must be in accordance with that allowed in the main software).

5.2.12 Password file should be stored separately from application data.


Page 37 of 58

5.3. Security of DataOverview:


5.3.1 Data input should be validated to ensure that data is correct and appropriate

5.3.2 Validation rules and ranges shall be configurable, where appropriate, by users with relevant access permissions.

5.3.3 Validation checks should be incorporated into the system to detect any corruption of information through processing errors or deliberate acts

5.3.4 Data output should be validated to ensure that the processing of stored information is correct and appropriate

5.3.5 Automatic time-out after user-defined period of inactivity.

5.3.6 The system to revert to main menu after a user-defined period of inactivity.

5.3.7 The vendor must recommend back-up and restoration procedures. These should be fully documented and ensure that all essential information and software can be recovered following a disaster or media failure.


Page 38 of 58

6.0. Legislative Requirements (Functionality)

6.1. Legislative Requirements & Other IssuesOverview:


6.1.1 The Vendor will be required to make such modifications to the software so as to ensure that it conforms to any change of legislation or new legal requirement that affects any function or facility of the software.

6.1.2 The Vendor must comply with the following Acts (and any recent additions) and must include facilities for appropriate subject access to all personal data:-

Data Protection Act 1998 Human Rights Act 2000 Sex Discrimination Act 1975 Race Relations Act 1976 Disability Discrimination Act 1995 Equal Pay Act 1970 Local Government Access to

Information Act 1985 Local Government Act 2000 Freedom Of Information Act 2000 Mental Capacity Act 2005 Health And Social Care Act 2008 National Health Act 2006

6.1.3 All software and hardware must comply


Page 39 of 58

with the EC DSE Regulations 1992 and any other relevant statutory regulations.

6.1.4 The system must be capable of complying, where necessary, with the single currency of the EMU to allow future payments to be accepted with this currency.

6.1.5 The system must comply with BSI standard 7666 for recording property related data.

6.1.6 Confidential Reporting Policy.The Council is committed to the highest possible standards of openness, probity and accountability. To emphasise that, it has in place a confidential reporting policy for all Vendors providing services under a contract.


Page 40 of 58

7.0. Levels of Service (Functionality)

7.1. General Levels of ServiceOverview:


7.1.1 The system must be fully network compliant.

7.1.2 The Vendor must provide a recommendation for the minimum network capacity required by the solution

7.1.3 The system must be capable of allowing up to the following minimum number of users, with the potential to increase this number to allow enquiry facilities for other staff within the Authority:-

Maximum number of users: 275 Number of concurrent users: 150

The system must also allow for additional users to access the system via the web.


Page 41 of 58

7.2. Systems Performance and TestingOverview:


7.2.1 Response times shall be within the following bands:-

On-screen search/enquiries – less than 2 seconds

On-screen update – less than 2 seconds

Simple enquiry – 1 minute Complex report – less than 15

minutes with no effect on system performance. The system must be fully network compliant.

7.3. PrintingOverview:


7.3.1 Ability to determine:- Number of copies of reports to be

printed Where appropriate, the output

type and location (e.g. Word format on file)


Page 42 of 58

7.3.2 Provide a print preview function prior to processing the print action.

7.3.3 Provide a facility to schedule report production as required by the user, or run ad hoc.

7.3.4 Printed output from environments other than live should be clearly marked as such

7.3.5 The system must allow reports to be formatted before printing.

7.3.6 All output must be printable in accessible format. (for example to allow the font size to be increased for visually impaired users or clients)

7.3.7 Print page must be available to users at all times

7.4. System Storage & Transactional VolumeOverview:


7.4.1 The size of the database must meet immediate and future needs with regard to account information held and transaction capability required in each of the main business areas. Information on the approximate number of client records is given in section 1.2

7.4.2 Vendors must make allowance for the


Page 43 of 58

permanent residence on the system of suitably sized training, test databases and application systems.

7.4.3 Each environment should be easily identifiable by the use of labels, colours, and warnings etc. to prevent accidental use.

7.4.4 The system must provide a locally controlled facility to copy live data to alternative instances (e.g. test, training or reporting)

7.4.5 The software shall provide the facility to generate a test version of the system.

7.4.6 The test version should be a fully functional version with all features available that are present in the live version.

7.4.7 Different user profiles should be available for live and test/ training/beta systems.

7.4.8 Storage requirements for the proposed solution should be categorised into discrete areas to make it easy to understand how the overall estimated storage requirements have been calculated (for the life of the project), areas such like but not exclusively to the list below;-

Software/application storage requirements.

Operational Data Storage (audit logs).


Page 44 of 58

Database Transaction Logs. Test/Development systems System Backup (to disk) Storage configuration overhead

(RAID)

7.5. Resilience and BackupOverview:


7.5.1 All system and application software changes and patches must be documented and subject to change control procedures.

7.5.2 Security copies and restores should be automatically logged.

7.5.3 Please advise on the proposed solutions resilience and availability providing details such as know issues, single point of failures, operational limitations etc.


Page 45 of 58

7.6. Systems Support and MaintenanceOverview:


7.6.1 The vendor must provide a Service Desk where issues can be logged via the web, telephone or email and where the progress of any issues can be tracked.

7.6.2 Support and maintenance shall be carried out in accordance with the Vendor Proposal and the Terms and Conditions of Contract agreed between the Vendor and Darlington Borough Council.

7.6.3 The system support will be available to operational staff within the Authority’s premises during normal office hours i.e. 8am to 6pm Monday to Friday and occasionally at weekends.

7.6.4 The council is moving towards a more efficient/flexible infrastructure and virtualisation is a key step in achieving this; therefore is the proposed solution or parts of the solution capable of being deployed in a virtual server and storage estate (if not a hosted solution).


Page 46 of 58

7.7. Code of Connection for Third Party Application VendorsOverview:


7.7.1 Remote access for systems maintenance and fault diagnosis should conform to the Xentrall – Access Controls and Security of Third Party OrganisationsSee Appendix A

Inability to comply with the Policy may result in remote access being denied.

7.8. TrainingOverview:


7.8.1 The Vendor must state the levels of training they recommend for key users of the system and what further training is available if deemed necessary (for example because of system enhancements or staff turnover).This also applies to both setting up and running the system and on setting up and configuring any WEB pages.

7.8.2 Documentation including administration


Page 47 of 58

and user manuals must be provided. 7.8.3 The Vendor must provide a training plan.7.8.4 Training documentation must be

provided for current and future releases.7.8.5 Training must be provided specifically for

report writing.7.8.6 The Vendor must advise on their

proposed methods for the delivery of such training (end user or train the trainer) detailing the different courses.

7.9. Future UpgradesOverview:


7.9.1 All future system upgrades:- Must be covered by the

maintenance agreement and accompanied by appropriate amendments to the documentation

All changes to the system must follow quality control and change control procedures

Copies of new releases must be provided by the Vendor

7.9.2 All new releases must include release notes and detailed notes to upgrade to the new release.

7.9.3 If required by new legislation, the Vendor


Page 48 of 58

shall implement modifications to the software as soon as reasonably practicable, but not later than two weeks prior to the date on which the relevant legislation comes in force.

7.9.4 The Vendor shall provide test versions of modified software as soon as is practicable, so that the Authority can test upgrades before implementation into a ‘live’ environment.

7.9.5 Allow local control for implementation of new releases and upgrades.

7.9.6 Provide a website detailing past, current and future versions of the software product.

8.0. Risk Management (Methodology)

8.1. Risk ManagementOverview:


8.1.1 The Vendor is required to provide a statement with regards to the involvement of, and arrangements for managing working relationships with, sub-contractors in providing the Contract

8.1.2 The Vendor is required to provide an example of a recent Risk Assessment or Method Statement specific to the nature


Page 49 of 58

of the work described in this specification.

9.0. Product Development (Methodology)

9.1. Product Development Overview: Overall approach to the future development of the proposed solution


9.1.1 The Vendor must provide information as to the future development of the proposed solution

9.1.2 The Vendor must provide information as to how the council can influence the future development of the proposed solution

9.1.4 The Vendor must advise if regular user group meetings exist, their location and frequency

9.1.5 The Vendor must advise if there are processes in-place which involving user groups in influencing the future direction of the proposed solution.

10.0. Project Management (Methodology)

10.1. Project ManagementOverview: The vendor is asked to document their provision of project management until acceptance of the last processes in this procurement.


Page 50 of 58


10.1.1 The Vendor must provide information on the provision of project management until acceptance of the last processes in this procurement.

10.1.2 The Vendor must identify the ‘Key Personnel’ in their delivery of the project management with CVs

10.1.3 The Vendor must appoint a Project Manager who will attend meetings arranged with the Council Project Team as necessary.

10.1.4 Any alterations to personnel must be subject to the Council’s approval.

10.1.5 Project management will include detailed project plans covering the System installation, pre-requirements from the Council, training, project configuration , rollout to users and System Acceptance

10.1.6 The plan will include estimated timings, milestones and critical dates.

10.1.7 The plan must be agreed with the Council.

10.1.8 The plan must be updated at least monthly.

10.1.9 Project management will include regular reports on progress in meeting those dates.

10.1.10 Project management will include meetings at least monthly between council staff and vendor personnel to


Page 51 of 58

resolve issues arising.10.1.11 Please calculate the number of days

required for project management and include it in the 14.1 Procurement Cost Breakdown section.

11.0. Implementation Specification (Methodology)

11.1. Implementation SpecificationOverview: The vendor is asked to provide a detailed draft Implementation specification which shall at least include the following areas:


11.1.1 Draft Implementation Specification to include:(Please provide the draft Implementation specification as a separate document)

Precise configuration of standard hardware, software and documentation to be provided/hosted

Precise specification of custom software and documentation to be provided

Precise specification of system configuration requirements

Predicted network impact Installation of proposed system

and all associated software / hardware components.

System commissioning Acceptance Testing


Page 52 of 58

System maintenance plans Project management Training Backup and disaster recovery

plans Exit plan for transferring data out

of the System at a later date Resources and services required

from the Council Implementation timetable.

11.1.2 The vendor will acknowledge that this draft Implementation Specification will be completed before the hardware and software purchase and will form Schedule 1 of the Agreement (Contract) between the parties.

11.1.3 The vendor will revise the Implementation Specification in later phases to update it as necessary to match software and hardware updates and availability of council resources.

11.1.4 The Vendor must provide details of support offered to facilitate testing as all software will be subject to acceptance testing by the Council’s Adult Social Care Section.

11.1.5 The Vendor must commit to providing sufficient resources to facilitate testing and identify any associated costs within the 14.1 Procurement Cost Breakdown section.


Page 53 of 58

12.0. Exit Strategy (Methodology)

12.1. Exit StrategyOverview: To guarantee the preservation and accessibility of the Council's data


12.1.1 The vendor will outline an exit plan as part of the Implementation Specification and

12.1.2 The Vendor will undertake to demonstrate the exit plan as part of Acceptance Testing.

12.1.3 The Vendor will undertake to provide costs for all the hardware, software and documentation necessary to export all data from their System in a format suitable for import into another system and include the cost in the 5.1 Procurement Cost Breakdown section.

12.1.4 The Vendor will undertake to calculate the number of vendor day’s services required to implement exit plan and include the cost in the 5.1 Procurement Cost Breakdown section.

12.1.5 Please comment on arrangements for an ESCROW agreement.


Page 54 of 58

13.0. Business Continuity Plans (Methodology)

13.1. Business Continuity PlansOverview: The Civil Contingencies Act 2004 requires the Council to maintain plans to ensure it can continue to perform all of its ordinary functions in the event of an emergency. Organisations providing services or goods which underpin the Council’s service provision must be able to continue to provide in the event of an emergency.


13.1.1 The Vendor is asked to provide a statement with regards to what measures and processes they have in place in respect of the above council’s duties in relation to the Civil Contingencies Act 2004.

14.0. Cost Breakdown (Value for Money)

14.1 Procurement Costs BreakdownThe following table must be completed detailing all of the procurement costs in relation to all aspects of the proposed system.

An electronic spreadsheet called ITT Schedule3 Appendix2 - ITT Pricing Schedule v1.1.xls is also provided to record the cost. The vendor is asked to replicate the costing information into this spreadsheet to facilitate the evaluation process.

Where a requirement has been rated by the vendor as ‘A – Included as standard in the proposed system’ then the provision for the requirement must be covered in the Procurement Costs and not itemised in the Optional Costs.

Ref Requirement Comment Cost £Initial Cost


Page 55 of 58

IC1 e.g. Proposed System; components individually itemised and priced.



IC4 …IC5 e.g. Installation and TestingIC6 e.g. TrainingIC7 e.g. Project ManagementIC8 e.g. Exit StrategyIC9IC….

ICT Initial Costs – Total:Other Related CostOC1 e.g. OS SoftwareOC2 e.g. Hardware OC3 e.g. Any hosting services individually itemised and

priced to support the proposedOC4OC5OC….

OCT Other Related Costs – Total:Annual CostAC1 e.g. Annual License AC2 e.g. Software MaintenanceAC3 e.g. Hardware MaintenanceAC4AC5AC….

ACT Annual Costs – Total:


Page 56 of 58

Note: Total Procurement costs for the contract will be calculated as follows, unless clearly stated otherwise by the Vendor:

ICT + OCT + (ACT * (Contract Period – 1 year))

14.2 Optional Costs BreakdownThe following table must be completed detailing all of the procurement costs in relation to all aspects of the proposed system.

An electronic spreadsheet called ITT Schedule3 Appendix2 - ITT Pricing Schedule v1.1.xls is also provided to record the cost. The vendor is asked to replicate the costing information into this spreadsheet to facilitate the evaluation process.

Where a requirement has been rated by the vendor as ‘A – Included as standard in the proposed system’ then the provision for the requirement must be covered in the 14.1 Procurement Costs and not itemised in the 14.2 Optional Costs.

The vendor is asked to detail any optional costs in the table below that may be beneficial to the project or proposed system. Optional costs could include extra system licences, consultancy day rates, project management cost, hardware provision, training rates, expenses etc.

Ref Requirement Comment Cost £Optional CostOPC1 e.g. Optional System Modules;

components individually itemised and priced.OPC2OPC3OPC4 …OPC5OPC…

OPCT Optional Costs – Total:


Page 57 of 58

Appendix A

ACCESS CONTROLS AND SECURITY OF THIRD PARTY ORGANISATIONS - POLICY ACCEPTANCE FORM

Please see embedded document; ACS_of_Third_Party_Organisations_Policy_Acceptance_Form v0.2.doc


Date post:	04-Oct-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

ITT Standard Sections - WhatDoTheyKnow€¦ · Web viewRefs A-E Tender Response 9.1.1 The Vendor...

Documents