Specification of ASSD IT System Requirements ...€¦ · Web viewProject Board meetings will be scheduled and referenced in the contractual project plan. The Supplier must provide

London Borough of BarnetAdult Social Services Dept.

Specification of ASSD future IT system requirements

Status: DraftVersion: 0.6Date: 30 September 2009 Doc Id: RqmtsSpec_V0-6

SPECIFICATION OF ASSD FUTURE IT SYSTEM REQUIREMENTS

Author: Mark Thomas

Version 0.6 Page 2 of 48


Table of Contents

1 Summary.......................................................................................................................52 Introduction / Background.............................................................................................63 Overview of ‘As Is’ Systems Landscape.......................................................................7

3.1 ‘As Is’ Systems Landscape - ASSD....................................................................73.1.1 SWIFT................................................................................................................73.1.2 Wisdom..............................................................................................................73.1.3 SAP....................................................................................................................73.1.4 APMS.................................................................................................................73.1.5 BOXI...................................................................................................................73.1.6 CM2000 CallConfirmLive!..................................................................................73.1.7 ICES...................................................................................................................83.1.8 On-Line Resource Directory...............................................................................83.1.9 ‘As Is’ Systems Landscape - SWIFT – Now.......................................................93.1.10 ‘As Is’ Systems Landscape - SWIFT – Near Future.........................................103.1.11 ‘As Is’ Systems Landscape – ASSD and Key Interfaces..................................11

3.2 ‘As Is’ Systems Landscape - Wider context.....................................................124 Business Requirements Overview..............................................................................13

4.1 Key Activities....................................................................................................134.1.1 Groupings of Key Activities..............................................................................134.1.2 Background Notes............................................................................................13

4.2 Business Vision................................................................................................134.2.1 ASSD................................................................................................................134.2.2 Council-wide.....................................................................................................14

4.3 LB Barnet’s new information technology strategy............................................144.4 Wider Considerations.......................................................................................14

5 Basic Principles and General Requirements...............................................................155.1 Design systems for the customers...................................................................155.2 Systems should support the business processes, not the other way around...155.3 System reliability..............................................................................................155.4 VFM..................................................................................................................155.5 ‘Input Once’ / Single ‘Front-End’ / Transparency..............................................15

5.5.1 ‘Input Once’......................................................................................................165.5.2 Single ‘front-end’..............................................................................................16

5.6 Consistent front-end recording practice............................................................165.7 Maximum Integration........................................................................................17

5.7.1 Electronic Forms (E-Forms).............................................................................175.7.2 Address formats...............................................................................................18

5.8 Easy to use.......................................................................................................185.9 Accessible........................................................................................................205.10 Secure..............................................................................................................20

5.10.1 General security features.................................................................................205.10.2 Third party access to LB Barnet systems.........................................................205.10.3 LB Barnet access to third party systems..........................................................20

5.11 Auditable..........................................................................................................215.12 Tools to drive excellent Data Quality................................................................215.13 Reporting / Outputs..........................................................................................215.14 Workflow fully utilised.......................................................................................22



5.15 Meets all statutory, regulatory and FACS requirements...................................225.16 Supports cross-organisation working...............................................................22

5.16.1 Working with Health (PCT and MHT and Hospital Trusts)...............................225.16.2 Working with other public sector partners........................................................235.16.3 Working with private sector partners................................................................235.16.4 Safeguarding issues.........................................................................................245.16.5 Corporate requirements...................................................................................24

5.17 Supports the Personalisation Agenda..............................................................245.17.1 Impact on Citizen Access to Social Care Information.......................................245.17.2 Impacts on Care Management.........................................................................245.17.3 Impacts on Financial Management...................................................................245.17.4 Impacts on Performance Management............................................................255.17.5 Impacts on the Brokerage function...................................................................255.17.6 Impacts on Strategic Commissioning...............................................................265.17.7 On-Line Resource Directory Customer Self-Service Portal.........................265.17.8 Other potential channels for delivering Citizen-Led solutions...........................285.17.9 Customer Relationship Management (CRM)....................................................28

5.18 Flexible, multi-dimensional views.....................................................................285.19 ‘Future Proofing’...............................................................................................295.20 Business Continuity & Data Recovery..............................................................295.21 Complete and adequate systems documentation, kept up-to-date..................295.22 Test and training databases.............................................................................295.23 Archiving...........................................................................................................30

6 Detailed Functionality Requirements...........................................................................316.1 Case Management Requirements....................................................................316.2 Performance Management Requirements........................................................31

6.2.1 Statutory returns...............................................................................................316.2.2 PAF Indicators..................................................................................................31

6.3 Strategic Commissioning Requirements..........................................................316.4 Contract Management Requirements...............................................................326.5 Financial Management Requirements (processing, reporting, analysis & monitoring; operational & strategic)................................................................................32

6.5.1 Housekeeping and synchronisation of account coding structure......................326.5.2 Systems reconciliations....................................................................................336.5.3 Budget monitoring and integrated financial and management information

reporting...........................................................................................................337 Wisdom – Electronic Document and Records Management System (EDRMS)..........34

7.1 EDRMS - corporate..........................................................................................347.2 EDRMS and the care management system.....................................................34

8 LB Barnet Technical Specifications.............................................................................358.1 Technical Landscape.......................................................................................358.2 Technical Requirements for application systems.............................................35

9 Conclusions.................................................................................................................3610 Next Steps...................................................................................................................36Appendices.........................................................................................................................37

Appendix A – Product Breakdown Structure...................................................................37Appendix B – High-level Product Descriptions for ASSD system requirements.............38Appendix C – List of current statutory returns and Performance Indicators (as at August 2009).............................................................................................................................. 39



Statutory returns as at August 2009............................................................................39PAF indicators as at August 2009...............................................................................39

Appendix D – Choice And Independence – A Vision For Adult Social Services.............42Appendix E – Adult Social Services Business Plan 2009-10..........................................42Appendix F – Online Resource system specification......................................................42Appendix G – Care Model Development Project............................................................42Appendix H – LB Barnet Address Standards..................................................................43

Background information..............................................................................................43Elements of an address record (mandatory fields in bold)..........................................43Data migration/load and maintenance........................................................................44Possible ASSD future uses for mapping data.............................................................44Technical specification and further reading.................................................................44Requirements for ASSD system(s).............................................................................44

Document Control..............................................................................................................45



1 SummaryLB Barnet’s perceived IT system needs for Adult Social Services have moved on significantly from those described in the procurement of Liquidlogic’s eSAP solution. As agreed when the contract was signed the review of ASSD has reviewed the requirements which are are now

Wider

Deeper

More customer-driven

ASSD’s requirements are now wider, as they now cover the totality of an Adult Social Services system solution. The requirements of the Performance Management, Strategic Commissioning, Contract Management and Financial Management functions, must all be satisfied, as well as Case Management. Although it is recognised that this ‘total solution’ need may be practically met by a number of different IT systems, integration is critical, both within the solution and with ‘external’ systems - corporate systems and those of our external partners such as Health agencies, care providers and other local authorities. ‘Input Once’ is the watchword. The idea of a single front-end portal is particularly appealing, ideally configurable to meet the needs of customers, LBB staff, Health staff, providers and other approved organisations alike. E-forms should be widely used.

ASSD’s requirements are now deeper, in the sense that we are considering enhancement to, or possible replacement of, our existing care management system. Consequently, Appendix B to this document goes into some detail about LBB’s specific functionality requirements, especially for case management.

ASSD’s requirements are now more customer-driven. Whilst this change is largely determined by the Personalisation Agenda, there is a general focus on business solutions, and the technology used to deliver these, being more citizen-led.

Overall, the ASS solution(s) must meet all statutory and regulatory requirements (especially for FACS and data protection, including Caldicott), now and in the future, and must satisfy LBB’s IT requirements (both technical and non-technical, e.g. ‘soft’ features). It/they must provide Value For Money and must be reliable, secure, auditable and designed to drive excellent data quality, whilst being future-proofed as far as possible. At the same time, the ASS solution(s) must also be widely accessible, easy-to-use, flexible, adaptable and take full advantage of the potential benefits of process improvement/efficiency features such as workflow.

Data quality considerations apply as much to reporting and other outputs, as they do to inputs and processing. Outputs should not only be secure (including appropriate access rights) and trusted, and therefore properly controlled and configuration managed, but also be flexible, on-demand and provide, through a number of appropriate delivery mechanisms and presentational formats, multi-dimensional views of the wealth of data stored, for business purposes known and not-yet-known.

Given the above, LB Barnet needs to understand how SERCO/Liquidlogic, and their partners, can satisfy the requirements stated within the original procurement, how much the additional requirements are likely to cost, and when the system(s) can be implemented. The Council also needs to understand where the gaps are in Liquidlogic’s offering, i.e. what cannot be achieved, even with (if applicable) an enhanced offering.



2 Introduction / BackgroundThe contract with Serco to procure Liquidlogic’s eSAP solution contained the following clause:

The Customer’s business requirements and strategy within Adult Social Services have undergone review between the time of undertaking procurement of the eSAP solution and the time of making this Service Order. As a consequence, the Customer’s functional requirements for the eSAP solution are likely to need to change, leading to possible revisions to the Specification, Contractor’s Proposal and the Charges. The parties agree that delivery of the eSAP solution in accordance with the contract will be subject to a prior review of the Specification, Contractor’s Proposal and Charges, in light of the Customer’s changing business requirements, and agreement to any revision to those items (in the event that agreement cannot be reached, the Customer having the choice of reverting to delivery as originally intended or removing provision of an eSAP solution from the contract), such revisions to be incorporated into this Service Order under change control.

On 19th February 2009 Mathew Kendall, Assistant Director, Performance and Supply Management, ASSD at LB Barnet, wrote to Liquidlogic. In his letter, Mathew referred to this clause, in the context of the need to “review Liquidlogic’s software’s ability to meet the London Borough of Barnet’s business needs for supporting adult social care in line with Putting People First and our vision for self-directed support”.

Mathew outlined 4 key activities to be undertaken by LB Barnet, 3 of which form the basis of this document:

1. Defining our detailed case management system requirements […] reflecting the remodelling of our case management procedures in line with the personalisation agenda.

2. Defining our broader information system needs, to reflect our aspirations for the use of technology beyond case management – for example, providing citizens with a portal for direct access to their case records.

3. Developing an understanding of how the requirements identified in 1 and 2 will need to fit with the Council’s new information systems strategy, which is being developed during the spring and summer of 2009.

Specifically, LB Barnet committed to providing Liquidlogic with “a Specification of Requirements, referencing the issues identified in 1, 2 and 3 in September 2009.” This is that document.



3 Overview of ‘As Is’ Systems Landscape3.1 ‘As Is’ Systems Landscape - ASSD 3.1.1 SWIFT

SWIFT is the Council’s care management database and is used to feed Performance Management reports (including the Statutory Returns and PAF Indicators). It also encompasses some financial functionality – the processing of provider invoices, billing Community Care clients under Fairer Charging, and (soon) Financial Assessments for Residential and Nursing clients.

Financial Assessments for Community Care clients (Fairer Charging) will remain on a bespoke spreadsheet system for the time being.

3.1.2 WisdomWisdom is the Council’s corporate Electronic Document & Records Management System (EDRMS), of which ASSD makes extensive use.

Together, SWIFT and Wisdom form the Electronic Social Care Record (ESCR).

As a corporate system, Wisdom will be retained for the foreseeable future. Any future ASSD solution(s) must therefore provide integration between the care management system(s) and Wisdom. Please also see section below.

3.1.3 SAPSAP is LB Barnet’s corporate enterprise management system, including

SAP R/3, which provides, inter alia, the main financial functionality for payables, receivables and budget management

SAP Customer Relationship Management (CRM) system, the use of which is to be developed further – see section below.

These corporate systems will be retained for the foreseeable future, so any future ASSD solution(s) must interface with SAP R/3 and SAP CRM.3.1.4 APMS

APMS is a data warehouse, containing performance and activity data from SWIFT only, designed for use with Business Objects (BO) – see below.

3.1.5 BOXIThis is the Business Objects XI reporting tool.

3.1.6 CM2000 CallConfirmLive!CM2000’s CallConfirmLive! system is a Web enabled electronic monitoring solution for the delivery of home care. Visit data is captured by the carer ‘logging on’ and ‘logging off’ at the beginning and end of each visit, using telephony based data capture technologies. Please refer to CM2000’s website for more details: http://www.cm2000.co.uk/home.aspx

Details of care commissioned from each provider are interfaced nightly to CallConfirmLive!, and the actual visit data is extracted each day by LB Barnet into a bespoke Oracle table, for onward calculation of the provider invoices to be paid.

Any future solution must provide integration between the care management system(s) and CallConfirmLive!.


http://www.cm2000.co.uk/home.aspx


3.1.7 ICESThe Integrated Community Equipment Service (ICES) is a service provided by Medequip Assistive Technology to supply equipment, major and minor adaptations and Telecare equipment to meet people’s health and social care needs.

Any future solution must provide integration between the care management system(s) and ICES.3.1.8 On-Line Resource Directory

This is designed to provide customers with an on-line directory of social care resources, including customer ‘star rating’ of providers and services, a customer discussion forum and an on-line Events calendar. It is currently under development – please see below for more details.

// Continued on next page …



3.1.9 ‘As Is’ Systems Landscape - SWIFT – Now

SWIFT (ASS)SWIFT (ASS)Case Management

Care Providers

ProcurementBudget

Management

Financials

Invo

ice P

roce

ssin

g

Besp

oke

Faire

r Ch

argi

ng B

illing

Ext

ract

Block Contracts

Personal / Demographic Data

Contacts / Referrals

AssessmentsOutcomes

Profi

le N

otes

Services

Care Plans

Revi

ews

Cost

edPa

ckag

es o

f Car

e

Dire

ct P

aym

ents

Accommodation (LD only)

Employment (LD only)

WORKFLOW (Limited use – for Financials only)

Care Offer-ings

Pricing

Wisdombutton

Legal Status

(MH only)Registers

Besp

oke

Mea

ls Bi

lling

Extra

ct

Carer’s Assessments W

ithin

‘A

sses

s’ ta

bLimited data sharing with other agencies at present. Intermediate Care and Hospital Social Work teams do input into SWIFT, but LBB does not have access to Health systems.

Note that billing of ASS clients (export to the corporate SAP Accounts Receivable system) is not achieved through SWIFT’s standard Billing & Collection module but rather via LB Barnet bespoke extraction routines.



3.1.10 ‘As Is’ Systems Landscape - SWIFT – Near Future

SWIFT (ASS)SWIFT (ASS)


ithin

‘A

sses

s’ ta

b


ithin

‘A

sses

s’ ta

b

Case Management

Care Providers

ProcurementBudget

Management

Financials

Invo

ice P

roce

ssin

g

Besp

oke

Faire

r Ch

argi

ng B

illing

Ext

ract

Block Contracts

Personal / Demographic Data

Contacts / Referrals

AssessmentsOutcomes

Profi

le N

otes

Services

Care Plans

Revi

ews

Cost

edPa

ckag

es o

f Car

e

Dire

ct P

aym

ents

Accommodation (LD only)

Employment (LD only) Pe

rson

al B

udge

ts

WORKFLOW (Limited use – for Financials only)

Care Offer-ings

Pricing

Wisdombutton

Legal Status

(MH only)Registers

SDS PBQ

RAS

Fin Ass (R/N)

ISP ?

Limited data sharing with other agencies at present

Besp

oke

Mea

ls Bi

lling

Extra

ct

The diagram above reflects the impact of SDS and the anticipated growing take-up of Personal Budgets.

LB Barnet will soon be implementing the Financial Assessments (Residential) module of SWIFT.

At some point in the near future, there is the possibility that the Independent Sector Payments (ISP) module of SWIFT will be used to pay residential and nursing home providers on a proactive, scheduler basis (instead of on invoice).



3.1.11 ‘As Is’ Systems Landscape – ASSD and Key Interfaces

Reporting databaseReporting database

ICESICES

BOXI

WisdomFinancial

Assessments(Bespoke spreadsheet

system, but assessments under CRAG will soon be

done in SWIFT)

APMS(Performance

&Activity)

Freedom PassesBlue

Badges

ReportsReports

SWIFTSWIFT SAP R/3SAP R/3Visit data

(Oracle table)

Swift/Wisdom ‘integration’

Billing (Comm Care / Meals)

Homecare Invoice

data

Payables

Bespoke data

extract

Universe

Off systems authorisation of

care packages by budget-holders

Safeguarding(Bespoke spreadsheet)

££ ££

Finance Deputies &

Protection of Property

MealsMealsMeals

Meals delivery

data

CM2000CM2000Commissioned Care

Purcha

se Orde

rs

LB E

nfiel

d

UniverseUniverse

Universe

CM2000 reporting

system

Meals

Provider Quality Monitoring

(Documents folder)



3.2 ‘As Is’ Systems Landscape - Wider context

Corporate Systemse.g. SAP R/3, SAP CRM,

contract management

Social Services

Adults ChildrenSupporting People

Social Services

Adults ChildrenSupporting PeopleCM

2000

Hom

ecar

e Mo

nito

ring

On-li

ne

Reso

urce

Dire

ctor

y

LBB

RiO

Heal

th m

anag

emen

tsy

stem

(some access to ASS systems)

(limited access to SWIFT)

RiO

Heal

th m

anag

emen

tsy

stem

Wisd

om

(non

-ASS

D us

e)



4 Business Requirements Overview4.1 Key Activities 4.1.1 Groupings of Key Activities

ASSD’s key activities can be grouped together under 5 primary headings:

1) Case Management

2) Performance Management

3) Strategic Commissioning

4) Contract Management

5) Financial Management

4.1.2 Background NotesFunctionally, ASSD is organised with a Supply Management function, which covers the Contract, Performance and Financial management activities and some of the Case Management activity (provisioning of care services).

Invoice Processing is not part of Finance at LB Barnet. This ensures that the Supply Management area maintains ownership of the relationship with the providers across the processes. However, from a systems functional point of view, this has been included in this Specification under the Financial Management heading – see below.

4.2 Business Vision 4.2.1 ASSD

In January 2007, Barnet Council’s cabinet approved a new vision for adult social care – please see Appendix D – Choice And Independence – A Vision For Adult Social Services. At the centre of this is a change in the way we work that provides people who use social care services and their carers with more control over the services they choose.

The Delivering Choice and Independence programme is a tool for making this vision reality. The future of ASSD must therefore be seen in the context of this programme and how we work with our partner organisations to ensure that they are offering a choice of new services which our customers want.

As part of the Delivering Choice and Independence programme, the front-line business model for care services is being remodelled in LB Barnet. This reorganisation of front-line teams is driven by the Personalisation Agenda. It is fully explained in the consultation paper referenced in Appendix G – Care Model Development Project. LB Barnet can make available, on request, the new care model procedures in their current draft form, for a more solid description of how some of our new teams will work.

Adult Social Service’s Business Plan 2009-10 is focussed on ensuring a strong and secure foundation for choice and independence. The Key Messages of the Plan revolve around:

Securing the foundation - Professional, effective, affordable practice


http://www.barnet.gov.uk/index/health-social-care/carers.htm

http://intranetlbb/commweb/Adult%20Social%20Services%202009/Delivering%20Choice%20and%20Independence%20Programme/ASSD%20-%20Vision%20Action%20Plan%20June2007.pdf

http://intranetlbb/commweb/Adult%20Social%20Services%202009/Delivering%20Choice%20and%20Independence%20Programme/ASSD%20-%20Vision%20Action%20Plan%20June2007.pdf


Moving forward on choice and independence

Managing within our resources

Please see Appendix E – Adult Social Services Business Plan 2009-10 for more details.

The Plan has impacts on case recording, commissioning and supply management and on financial management. Also, Performance Management has to reflect the new realities with appropriate Indicators (see section below).

4.2.2 Council-wideAny developments must also fit in with the Council’s ‘Future Shape’ strategy

“The Future Shape programme was set up […] to look at how Barnet could tackle the challenges of meeting higher expectations from our residents with less money. […]The programme is about how we do things differently in future to help make sure Barnet’s citizens can lead successful and comfortable lives and fulfil their potential. It concludes that we need to focus in particular on three areas:

a different relationship with citizens

a one public sector approach – working with our partners across the borough

a relentless drive for efficiency.” 1

It should be noted that the second Future Shape Report is currently in the process of being finalised. This contains reports on (a) access, (b) assessment and (c) commissioning (a.k.a. ‘the vehicle’). Once this Report is approved and becomes available, we can supply this as supplementary information to this Specification.

4.3 LB Barnet’s new information technology strategy This strategy is in the process of being defined.

4.4 Wider Considerations Although this specification does not encompass the requirements of Supporting People or the Children’s Service, there is an aspiration to be better integrated with these services. For example, the Transitions process would be greatly facilitated by being able to ‘port’ most of the standing data about the customer from the Children’s Service system(s) to the ASSD system(s).

1 Extract from Future Shape Executive Summary (June 2009)



5 Basic Principles and General Requirements5.1 Design systems for the customers

Systems should be designed so that they are accessible to, and meet the needs of, customers (service users). This should be complemented by them also meeting the requirements of LB Barnet’s staff.

In particular, the system solution(s) should support LB Barnet’s increased responsibility to its customers under the Personalisation Agenda - see section below.

All the other system requirements should facilitate customers getting the appropriate services, when they need them, at a fair price.

5.2 Systems should support the business processes, not the other way aroundWorkers should be provided with an IT environment that encourages them to get it right first time, rather than constantly dealing with the effects of recording problems. The right information should be at the end-user’s fingertips – be they LB Barnet staff, customers, business partners, etc. We believe that having business systems that support processes makes this possible.

If customers are satisfied, there will also be less stress on front-line staff, who will be better enabled to support those customers, thus promoting a ‘virtuous circle’.

5.3 System reliability The core systems and the surrounding IT infrastructure should all be robust and reliable, and the systems should make the best use of the infrastructure. LB Barnet’s technical requirements are set out in section 8.

5.4 VFM The ASSD system solution(s) should provide Value For Money (VFM)

Effective solutions

Efficient solutions

Economic solutions

The term ‘economic’ refers to both the initial capital investment and to running costs, in terms of both people (project team, system-users, support staff, etc.) and systems (software, hardware, consultancy, maintenance, etc.). This concept is captured in the table below.

People Systems

Capital investment £££ NOW £££ NOW

Running costs £ ONGOING £ ONGOING

5.5 ‘Input Once’ / Single ‘Front-End’ / Transparency ’Input Once’ should be a guiding principle underpinning the system solutions. Specifically, for care management practitioners, input into a single front-end portal. Care practitioners would like to access all their work tools through a single log-on,



including E-mail; they wish to no longer “get lost down too many corridors” as they try to carry out their work.

5.5.1 ‘Input Once’The data should be common wherever possible. It may be shared or synchronised

Shared – held in 1 place, accessed by several screens / modules / systems. A significant caveat is that a shared approach must not contradict LB Barnet’s commitment to corporate systems such as SAP and Wisdom.

Synchronised – held in several places but additions, deletions and updates in 1 place are synchronised with all other areas – need rules for conflicts as to “which system wins” or reported to a human to decide? This is also a potential issue for the pre-population of E-Forms with data (see item 15 in ‘Product Description A.22.1: Electronic Forms – Flexible Content, Structure & Appearance’ in Appendix B – High-level Product Descriptions for ASSD system requirements).Synchronisation should be at defined intervals. Although a nightly routine may be typical, it should be possible to synchronise at any frequency, from virtual ‘real-time’ through to monthly or even annually.

Key fields will need to be specified to identify common records, e.g. the Single Patient identifier (see below).

5.5.2 Single ‘front-end’There should be a single ‘front-end’ for most groups of end-users (e.g. an ASS portal for duty teams and care managers)

The end-user, be they Barnet staff or a customer, does not need to be concerned with, or even be aware, what back-office systems they are using at any point in the process. The data input should be intelligently routed to populate the correct fields and tables in the relevant systems and databases; sometimes the data will be required by 1 system only, other times by more than one e.g. Social Care and Health systems (see more at section 5.16 ‘Supports cross-organisation working’).

Data enquiries and reporting should be able to bring together the information required by the end-user, regardless of where it is stored. Maybe a tool such as SharePoint2, or VisionWare’s MultiVue Identification Server3 is appropriate.

Failing this, all relevant systems should be available to appropriate authorised staff at all Council locations, including partner agency systems (especially RiO); also through other access routes – see section 5.9 ‘Accessible’.

5.6 Consistent front-end recording practice Whist recording practice has to move with changes in legislation, regulation, business models, etc., the “tail should not wag the dog” when back-office systems or report formats change. The front-end portal should be able to cope with changes to underlying systems and databases, and to changes that way information is to be presented in reports, without requiring the care practitioner or customer to change the way they record things each time. For the former, re-training is required, issue of

2 Microsoft Office SharePoint Server “enables enterprises to develop an intelligent portal that seamlessly connects users, teams, and knowledge so that people can take advantage of relevant information across business processes to help them work more efficiently”.3 “MultiVue enables organisations to provide and maintain a complete and accurate view of an entity […]” – see www.visionwareplc.com


http://www.visionwareplc.com/


new guidance, etc.; for the customer, they may well stop using the portal at all unless the changes bring demonstrable benefit to them.

5.7 Maximum Integration The ASSD system solutions should offer maximum integration. As well as the ‘Input Once’ principle and the idea of a single ‘front-end’ (see above) the aim should also be to make maximum use of flexible Electronic Forms.

5.7.1 Electronic Forms (E-Forms) Wherever possible, E-Forms should not be system-specific

o E-Forms should not be tied to a specific module or screen in a system, i.e. can populate data anywhere in the database, regardless of supplier’s standard user interface (subject to appropriate security update permissions and a full audit trail).

o E-Forms should not be tied to a specific underlying system or database (although there may be a primary link to a particular system – see below), i.e. can be used to populate appropriate data in different and/or multiple systems, as required, e.g. certain assessment data in Social Care and Health (RiO) systems, care provision required only in Social Care system, follow-up hospital appointments only in Health system. In particular, data that is common to the ‘core’ social care system and the EDRM system should be saved to both.

E-forms should update the relevant system(s) / databases(s) as soon as possible

o Where completed ‘on-line’, E-Forms should automatically populate relevant databases when form is ‘saved’ - system-user confirmation required

o Where completed ‘off-line’, E-Forms should automatically populate relevant databases when form and/or mobile device is next ‘synchronised’ with the relevant system(s) - system-user confirmation required

The Council is open to considering the use of generic E-forms included in software such as Ebase (transactional Web applications software) that is not linked to a particular market, but rather is used to build a bespoke database and forms for the specific business need. Ebase Technology (www.ebasetech.com) already offers a social care self assessment tool called EDM Platform (based on the CSAW system developed for Kent County Council) – see the attached (embedded) document

(double-click to open).

Having said that, LB Barnet is also open to E-forms being primarily linked to one system (such as Liquidlogic’s IAS), so long as they provide all the functionality we require, and meet the requirements laid out above re. populating multiple systems, etc.

Updates to E-Forms and to underlying systems

Wherever possible, updates to E-form templates should not require unnecessary changes in the underlying systems, and vice versa. Clearly, if completely new


http://www.ebasetech.com/


types of information need to be captured, both the systems and the forms will need amending to achieve this, but other kinds of changes on one side should not impact the other side, e.g. presentation changes to forms, screen changes on systems.

If resultant changes are required (to either the templates or the underlying systems), these should be easy and cheap to implement.

More about LB Barnet’s requirements for E-forms is set out in Appendix B, in ‘Product Description A.22.1: Electronic Forms – Flexible Content, Structure & Appearance’ through to ‘Product Description A.22.5: Electronic Forms – Configuration Management’.

5.7.2 Address formatsIt is important that address formats are consistent and standardised. Methods to achieve this include linking addresses to the Local Land and Property Gazetteer (LLPG) or (if out-of-borough) the National Land and Property Gazetteer (NLPG) and ensuring they conform to the British Standard, BS 76664 (LLPG and NLPG do). The Unique Property Reference Number (UPRN), which is allocated to every property in England & Wales, is the key reference field, and as such the ASSD system(s) must be capable of holding this at a minimum.

The ability to accept data in DTF format is also highly desirable.

Please refer to Appendix H – LB Barnet Address Standards for more details.

5.8 Easy to use The ASSD system solutions should be easy to use. Front-line staff need to be very clear as to what they need to record, how and when, and it should be as easy and intuitive as possible for them to carry out these tasks in minimum possible time whilst recording complete and accurate data. This should encourage the rapid embedment in the day-to-day work culture of those changes enforced by new ways of working and new technologies.

Recording should be quick and easy to enable quick sharing of information and speedy responses to customers.

The harder and more complex the input processes are, the data input will be more prone to error and the longer it will take, on average, to complete a given input task, and thus the cost of the input staff will be greater.

Simpler systems and simpler processes will mean less training and less need for a high level of IT skills in care practitioner staff, who primarily need their social care skills to do their jobs (which is why they were recruited in the first place).

Ease of use is particularly important wherever there will be direct use by customers themselves, e.g. offering a pictorial presentation wherever possible – see section below.

Qualities which would make the systems easy-to-use include:

Consistent ‘look-and-feel’ across the system, incl. the use of function keys, drop-down menus, and mouse operations.

Automatic transfer of common data between screens, e.g. name and address (minimal re-keying required).

4 BS 7666: 2006 Spatial datasets for geographical referencing



Maximum use of drop-down boxes

Flexible search facilitieso Search on any mandatory field (essential) + other key fields (desirable)

o Search on any appropriate combination of mandatory/key fields

o Flexible search criteria, e.g. use of wildcards, pattern searching (“sounds like”), contains/does not contain, greater/less than.

Logical & consistent navigationo Customisable Process Navigation options. It would be useful for there to

be a facility to automatically guide system-users through key business processes – these business processes, and the classes of system-user, to be definable by the Council. Further details of this requirement can be found in ‘Product Description A.23.3: Processes Navigation’ under Appendix B – High-level Product Descriptions for ASSD system requirements.

o Easy to follow – up-and-down ‘trees’, across modules, etc. Easy summary screens should link to the supporting detailed information just one-click away.

o ‘Back’ and ‘Forward’ navigation keys

o User-definable list ordering e.g. by selected fields, AZ or ZA, most recent oldest, ascending/descending value.

o Navigation on closure of item selected from a list.

Having selected a data item / object from a list, and then closing that item/object, the system should take the user to a logical place appropriate to the context of the enquiry or transaction being carried out, e.g. return to top of list, return to previous position in list, move directly to next item. The system should allow user customisation of this feature (e.g. like many E-mail programs do).

Note BookThere should be a free-text note book facility, accessible from around the system(s), which should use a flexible editor including spell-check (see below). However, access to this facility should be configurable and controllable by LB Barnet, to prevent and/or discourage system-users from circumventing, or otherwise violating, business processes by inappropriately storing information somewhere that is not standard and cannot be interrogated as easily as standardised fields.

Spell-checkAcross the system(s) and E-forms, there should be a spell-check facility (preferably integrated with MS Word or, if not, offering the same basic functionality and intuitively similar to use). There should also be intelligent system-generated prompts to run this before finalising certain processes, to be defined by LB Barnet (e.g. completing an Assessment)

Context-sensitive help and prompts – see also Data Validation tools

Intuitive use, based on the ways of using systems which people are familiar with (typically MS Office tools, such as personal folders)



5.9 Accessible The ASSD system solutions should offer maximum accessibility (subject to all necessary security access restrictions – see below).

Examples include

Web-enabled - meeting international accessibility standards

Full integration with MS Office (Outlook, Word, Excel, etc.) and other commonly-used formats such as PDFs

Equalities issues addressed, e.g. voice recognition software (such as Dragon), screen reader software (such as Jaws), keyboard shortcuts (interaction should not all be mouse dependent)

Mobile Working, e.g. Tablet PCs, mobile ‘phones (voice and text e.g. instant messaging), PDAs. Should enable working both ‘on-line’ and ‘off-line’ as appropriate.

Mobile printing facility

5.10 Secure 5.10.1 General security features

The ASSD system solutions should offer maximum security (whilst being fully accessible to those who have appropriate access permissions – see above. In particular, systems must:

Meet all LB Barnet general IT security requirements

Offer fully configurable role and user-based security access

Provide additional security appropriate to Mobile Working

It is also desirable to have field level security – it should be possible to apply access permissions at a lower level than screen/tab.

5.10.2 Third party access to LB Barnet systemsFor example, LB Enfield manage the Meals contracts for LB Barnet and therefore require access to LB Barnet’s social care system; but it should be possible to restrict / constrain what records they can see (read-access) and what records they can touch (write-access). There should be water-tight legal contracts to ensure compliance with all legislation (e.g. Data Protection Act).

5.10.3 LB Barnet access to third party systemsLB Barnet will require access to the systems of partner organisations. Particularly important is access to Health systems (NHS Spine, RiO, etc.), but not restricted to this – please see section below. Of course such information sharing needs to comply with Data Protection Act requirements. These requirements, and other particular security issues around these accesses and/or integrations must be met by the system(s) solution(s).



5.11 Auditable There should be secure audit trails of system activity, covering

On-line enquiries Secure audit trail of all data sources/fields addressed by system users on-line, showing date, time and user accessing the record

Reports run Secure audit trail of all data sources/fields addressed by all reports produced, showing date, time, author and requestor of the report

Updates Secure audit trail of all fields modified and by whom and when. Key data should be captured of previous record status (i.e. what the record showed before it was changed). How many iterations of change are retained must be configurable to the Council’s requirements.

Audit Trail reports should be available, both as standard and the facility for the Council to design its own reports on all or any audit trails. In relation to the electronic storage of documents (Wisdom) there must be compliance with TNA (National Archives) standards.

5.12 Tools to drive excellent Data Quality Excellent data quality is an essential business requirement across the board. It is therefore vitally important that system solutions assist in assuring data quality, especially the identification and correction of ‘poor’ and inconsistent data.

To this end, for each system there should be a data schema and data dictionary providing clear unambiguous identification of all data fields, tables and entities. Other examples of tools to drive data quality include extensive training and help facilities, various types of input and deletion restrictions (e.g. mandatory fields, field pre-formatting), and data validation tools (including exception reporting). For more detail, please refer to Appendix B – High-level Product Descriptions for ASSD systemrequirements, ‘Product Description F.7: Data Quality’. The system solution supplied should contain a wide range of these tools as an integral part of the system offering.

5.13 Reporting / Outputs Reports and other outputs (e.g. letters) must be trusted by the system-users, and only be available to those with the correct access security rights. Data quality considerations apply as much to the system outputs as they do to the inputs and processing; excellent data quality is vital in all 3. To this end, there should be good configuration management of outputs.

Delivery mechanisms should also be flexible and appropriate. Some reports, including some current Business Objects outputs, may be more appropriately delivered within the core system, as on-line enquiries, rather than through the ‘reporting’ tool. This should ensure up-to-date information at the user’s fingertips, whereas traditional reports are potentially out-of-date as soon as they are produced. The approach should largely depend on, inter alia, how ‘real-time’ each specific reporting requirement is.

The general qualities required of system reports and other outputs are outlined in ‘Product Description F.8: Outputs (reports & documents)’ in Appendix B – High-level Product Descriptions for ASSD system requirements.



5.14 Workflow fully utilised There should be flexible workflow functionality in the system(s) solution(s). Full advantage should be taken of this facility, to assist the business to be more efficient and to move towards a ‘paper light’ office. More detail can be found in Product Descriptions A.23.1 and A.23.2 in Appendix B – High-level Product Descriptions for ASSD system requirements.

5.15 Meets all statutory, regulatory and FACS requirements Meet Fair Access to Care Services (FACS) requirements, particularly in the

assessment, care plan and review processes – see ‘Product Description A.14.2: FACS analysis’ in Appendix B – High-level Product Descriptions for ASSD systemrequirements.

Conform to all data protection and information-sharing laws, protocols, etc., including Caldicott rules where information is to be shared with Health agencies.

Meet statutory requirements for electronic forms – see ‘Product Description A.22.2: Electronic Forms – Statutory/Regulatory Purposes’ in Appendix B – High-level Product Descriptions for ASSD system requirements.

Meet statutory reporting requirements – see ‘Product Description B.3: Central Government Returns’ in Appendix B – High-level Product Descriptions for ASSD system requirements.

Meet changes imposed by legislation (see also ‘Future Proofing’ section) e.g. from the Green Paper ‘Shaping The Future of Care Together’, the revised National Indicator Set (from April 2011) and the requirements of ‘Putting People First’ and the ‘Putting People First Milestones’ published by ADASS, DH and the LGA in August 2009.

5.16 Supports cross-organisation working 5.16.1 Working with Health (PCT5 and MHT and Hospital Trusts)

ASSD system solutions should connect to Health systems, e.g. RiO. Information Sharing Agreements will need to be set up (although this should not be a problem). Within the parameters set out in these Agreements, there should be a joint ASSD/Health ‘virtual office’. Consideration should be given to developing a single ‘portal’ for use by Social Services and Health staff and others (customers, etc.), as a further development of portals discussed elsewhere in this document – please see sub-section 5.17.7.6 ‘Single Portal’.

5.16.1.1 Single Patient Identifier The NHS Number of a customer should be used as the Single Patient Identifier across all systems. Additionally, a range of patient identifier numbers should be available (e.g. Social Care system ID, a Council-set Citizen Number)

5.16.1.2 Customer diagnoses and conditions Social care needs analysis would be improved by having information about individual customer’s diagnoses and conditions, e.g. stroke, dementia.

5 NHS Barnet has now had certain functions split out – a Commissioning agency (just hospital care commissioning for now, but Mental Health and Community Services commissioning will follow) and Autonomous Provider Organisations (APOs) to deliver services; the PCT will eventually be restricted to the main function of payment of GPs



5.16.1.3 Client assessments Particular client assessment types, such as the Single Assessment Process (SAP) and the Common Assessment Framework (CAF) for Adults, and the requirements of Care Programme Approach (CPA) recording, require joint working with Health agencies. The processes need to be streamlined and the tools need to evolve, e.g. there is a proposal (not yet approved) to pilot the use of MH Recovery Star as a tool to achieve an outcome focussed care plan for Mental Health customers.

The system(s) should also enable client and carer self-assessments – see Self-Service Portal in section below.

5.16.2 Working with other public sector partnersThere may need to be links to and from other partners’ systems (e.g. the Meals contract managed by LB Enfield). The security issues around this are briefly discussed in sections 5.10.2 and above.

5.16.3 Working with private sector partnersThe solution(s) should also facilitate working with private sector partners too e.g. providers’ own systems, as well as CM2000 CallConfirmLive!

5.16.3.1 CM2000 CallConfirmLive! Although this home care monitoring system is a key component of LB Barnet ASSD’s current system landscape (please see section above), concerns have been expressed that the present restriction of data capture to land-line telephones (or office input) may potentially work against the Personalisation Agenda, as it is based around a traditional model of care always delivered in the client’s own home. Investigations are at an early stage into the potential use of mobile devices to log the services delivered (e.g. the CACI tool being used by Barnsley Borough Council).

5.16.3.2 Access to provider systems Both the Council and the individual customers should have access to relevant parts of providers’ systems, e.g. to place electronic Purchase Orders – see section 5.17.7 ‘On-Line Resource Directory Customer Self-Service Portal’.

Authorised Council staff should have direct access to specific areas of provider systems on a secure line (where those systems can and do provide such access), to pass information typically at present sent as a password-protected MS Word document by E-mail. The security issues around this are briefly discussed in section above.

5.16.3.3 Provider access to ASSD systems Approved providers should also have tightly controlled access to LB Barnet’s ASS system(s). Possible uses include:

1) For providers to input, into the case management area, information regarding individual customers. This may be used as a simple dialogue tool with care management, e.g. to agree issues, etc.

2) For providers to share information with the Council about developments / changes in their business, e.g. expansions, new care offerings. This would increase LB Barnet’s intelligence about the marketplace.

3) Clearly such access should be through a secure portal with appropriate security and subject to appropriate legal agreements that comply with all



legislation (e.g. Data Protection Act). The security issues around this are briefly discussed in section above.

Other private sector partners may include advocacy services and other voluntary agencies.

5.16.4 Safeguarding issues Potential system providers should explain how their solution(s) will achieve the early flagging of Safeguarding issues to partner agencies and providers.

5.16.5 Corporate requirementsASSD systems must work in harmony with corporate system requirements e.g. Barnet CRM – see section below.

5.17 Supports the Personalisation Agenda To support the Personalisation Agenda, Adult Social Services’ business systems need to empower citizens who have an interest in social care. This will require systems adapting to:

a) support Adult Social Services’ revised business model – which adapts processes and forms to deliver citizen-directed case management;

b) support citizen access to social care information, both in terms of how that information is presented and what media it is presented on.

5.17.1 Impact on Citizen Access to Social Care InformationLB Barnet needs to incorporate Citizen-Led Technology into its business solutions. ASS information and systems should be more accessible, and available via multiple channels and media, and give the customer opportunities to take proactive actions such as purchasing care services, and enter into electronic dialogue with the Council – see 5.17.7 and below.

5.17.2 Impacts on Care ManagementThe fundamental business process is different to the ‘traditional’ model and will require new business procedures – please see above. Examples include

Self -Assessment, Self-Planning and Self-Review – potentially through the Customer Self-Service Portal (see below)

Facilitation and support of the determination and allocation of Personal Budgets6

via a Resource Allocation System (RAS).

Tracking of how customers are spending their Personal Budgets and flagging of potential Safeguarding issues (see below).

Support Planning and other Care Management functions being conducted by agencies other than the Council

5.17.3 Impacts on Financial ManagementSystems will need the flexibility to support citizens accessing social care funding through mechanisms alongside the current options of (a) council-managed funding and (b) direct payments. This may include (not an exhaustive or exclusive list) Individual Service Funds and pre-paid cards.

6 a.k.a. Individualised Budgets



Systems will need to support self-management of personal budgets. This will need to simultaneously provide LB Barnet with means of monitoring expenditure, especially where there are Safeguarding concerns. Please see also ‘Product Description C: Strategic Commissioning’ in Appendix B – High-level Product Descriptions for ASSD system requirements.

One method would be an on-line account accessible via the Self-Service Portal and/or other media (see 5.17.7 and below), where the customer requests what the money should be spent on but where the Council carries out the transactional processing. Customers should be able to vary spend by, e.g. cancelling certain visits, to store up the money for later use. Limits and tolerances would probably need to be set around what can and cannot be spent, both in general financial terms (e.g. cannot spend more than 1/10th of annual Budget in any 1 month) and linked to the Care Plan and/or set by the Risk Plan (e.g. customer must have at least one daily visit). An expected expenditure profile over the year should be set for each customer at the outset (with option to modify at the beginning of each year), and if expenditure is outside certain parameters then appropriate officers (e.g. key worker) should be automatically alerted.

There is a report (part of the national Personalisation toolkit) which addresses these issues across a range of options - see the attached (embedded) document

(double-click to open).

5.17.4 Impacts on Performance ManagementNew PIs will be required and there will be new ways of looking at some existing PIs. A new set of National PIs will be in place in April 2011. The supplier must commit to ensuring that the system reporting suite meets all these.

There will be accountability issues, particularly where Council does not have control over all of a given activity. The system(s) solution(s) need(s) to support the Council in its need to work with Health and with the voluntary sector to ensure that all activity is captured and counted in both local and national PIs.

Moving forward, questions will be asked as to how meaningful are deadline-driven PIs where the Council does not have control over some/all of the deadline-driven activity. For example, NI 130 Self-directed Support (Personal Budgets and direct payments) falls into this category. Delays in this process will in turn have a negative impact on NI 132 (assessments waiting time exceeding 28 days). The system(s) solution(s) need(s) to address these issues.

5.17.5 Impacts on the Brokerage functionThe main impact of the Personalisation Agenda and SDS for LB Barnet’s Supply Management teams is on the Brokerage function. The nature of the services procured will almost certainly expand beyond the ‘traditional’ care services to different kinds of purchases, e.g. gym memberships, gardening.

ASSD system(s) therefore need(s) to be flexible enough to incorporate a potentially endless and constantly evolving list of types of care provision without creating an unsustainable system administration overhead.



5.17.6 Impacts on Strategic CommissioningThe Strategic Commissioning function has to develop a consumer-led market in Barnet. For example, as highlighted in the recent Putting People First milestones, we need to develop ways of capturing information about individual choices (specifically, how individuals are choosing to spend their Personal Budgets) so that we can commission in response to this, i.e. linking ‘micro’ procurement decisions to ‘macro’ commissioning ones.

5.17.7 On-Line Resource Directory Customer Self-Service Portal5.17.7.1 Purpose / Content The minimum requirements for the on-line resource directory are outlined in ‘Product Description A.13.5: Online Resource Directory for Customers’ and expanded upon in the specification document produced by the Choice and Independence Programme Team – please refer to ‘Appendix F – Online Resource system specification’.

LB Barnet would look to develop this further into a Customer Self-Service Portal. Such a facility should incorporate an online procurement service linked to provider websites and/or databases, as outlined in ‘Product Description A.13.6: Online procurement service’. The customer should be able to ‘pick-and-choose’ services on offer from the provider, via an Amazon-style ‘shopping basket’, providing a ‘ready reckoner’ of the cost of the services being added to the basket and leading to an electronic ‘checkout’, which would then generate an electronic PO. This facility should also be available to citizens who are Self-Funders.

Going beyond this, the Self-Service Portal should also offer potential customers (people thinking about social care in the future, for themselves, relatives or friends) useful information obtained from ASS systems and provider systems as appropriate, such as the average Personal Budget in Barnet for the current year for an older person, for a person with a learning disability, etc. and the type of services typical customers purchase with this money. In particular, if a potential customer inputs basic details about themselves e.g. age, principal needs, the Self-Service Portal should be able to give them an idea about how much help the Council is likely to be able to provide, including an Indicative Personal Budget. This should mean better-informed citizens and a reduction in the instances of people approaching the Council in a crisis.

The Self-Service Portal should be one route for Self-Assessment, Self-Planning and Self-Review.

5.17.7.2 Links Need to consider links to existing systems such as SWIFT and CM2000. Although this facility will start off as directory of services, it will develop into a much more powerful tool, drawing on key data in other systems, especially the care management system and the ESCR (EDRMS).

The interaction with clients needs to move beyond the ‘old-style’ Council-led interaction (based on the information provided by the traditional back office functions) towards a customer-led model.

The Self-Service Portal should also be capable of feeding information back into the ASS systems, linking to Personal Budgets, SDS Support Plans, activity records, etc., and generating financial commitment records if appropriate.



5.17.7.3 Presentation of information and interaction with customers We need to define the types of interfaced integration LB Barnet will need to provide to customers. It may not just be the ASSD Self-Service Portal but also via portals used for other service-oriented offerings to the public, such as the SAP CRM portal.

It is desirable to present personalised data to the client via the Self-Service Portal, to answer a wider range of questions, e.g. “I applied for some OT equipment a week ago – what’s happened?”, “what’s my Personal Budget?”, “when will a social worker next review my case?”.

The user interface should be particularly intuitive and easy-to-use, e.g. pictorial presentation wherever possible.

LB Barnet would wish to link the ESCR (EDRMS) to the Portal, e.g. so a customer can download a copy of a letter.

There should be facilities for a dialogue with the customers, giving them the opportunity to update the Council, e.g. how they are using their Personal Budget, issues with their Support Plan. There could be an on-line care planning tool for collaborative working between social workers and customers.

Not only will such tools empower LB Barnet’s customers but they also offer the prospect of freeing up staff time, as customers carry out certain routine recording functions themselves.

Example of an on-line self-planning and purchasing tool is Shop4Support – see shop4support website.

5.17.7.4 Security and Data Protection issues Looking at the portal, especially the requirements discussed in above, ASSD needs to make decisions about a number of issues relating to security and data protection. These include (but are not restricted to) identification and validation of the on-line user, and distinguishing between different requirements, and thus different access rights, of different users; these points need to be considered with reference to both different customer classes/types and individual customers.

Potential solutions providers must provide evidence that their solution(s) offer wide-ranging and flexible functionality and standards adequate and sufficient to meet LB Barnet’s security and Data Protection requirements, and which conform to LB Barnet’s technical capacity, infrastructure and performance requirements and constraints – see also section 8 ‘LB Barnet Technical Specifications’.

5.17.7.5 Access to the Web facility The Web facility, both in its earlier resource directory and later Self-Service Portal guises, should be widely accessible, including:

Customers

Carers

Self-Funders

Potential Customers

Interested agencies

LB Barnet staff, e.g.


https://www.shop4support.com/S4S/UI/Content/


o Care practitioners

o Brokers

o Payables staff

o Staff at Customer Service Centres, wherever they may be situated around the Borough. This will allow customer service staff to assist customers with their queries.

Health staff (see ‘Single Portal’)

5.17.7.6 Single Portal LB Barnet is open to the idea of a single front-end Portal for both the Customers and LB Barnet staff, provided it is flexible enough to ensure all security and Data Protection and Consent for Information Sharing requirements are fully met, e.g. modular approach to information datasets.

This could potentially be extended to Health staff and systems, provided that there is full compliance with the stringent additional requirements relating to confidentiality of patient data (Caldicott rules, etc.).

5.17.8 Other potential channels for delivering Citizen-Led solutionsThere are potentially multiple appropriate channels through which to interact with the customers. LB Barnet should be led by the technology the customers/citizens wish to utilise, e.g. digital TV, tablet PCs, SMS/MMS, Twitter.

5.17.9 Customer Relationship Management (CRM)LB Barnet is currently planning to develop its SAP CRM system, focussing initially on transactional services (e.g. Council Tax). It is important that the ASSD system solutions integrate with the Council CRM solution.

The CRM has potential functionality to manage on-line purchasing; if this is implemented, the ASSD on-line procurement facility should utilise this.

5.18 Flexible, multi-dimensional views Although the person-centred approach has been appropriate to the traditional care management models, in the future the Council needs to be able to approach ASS questions, data, etc. from a number of different dimensions, whilst of course keeping the Customer at the centre of everything we do. Examples include linking of Customers to certain markets or health factors / lifestyle choices (e.g. smoking, diet, etc.). LB Barnet would look to make intelligent use of the rich data collected e.g. profile of smokers across the borough. System features that would facilitate this aspiration include:

1) Ability to define any field we require – see also Future Proofing (section below)

2) Intelligent interrogation / analysis of unstructured data e.g. free notes fields

3) Flexibility of reporting suite – allowing us to define queries that (a) can pick up any new fields defined and (b) report on unstructured data

4) Ability to target people on the basis of specific fields e.g. anyone with dementia sent specific mail shots re key health messages



5.19 ‘Future Proofing’ It is vitally important that the system(s) solution(s) offer flexibility, adaptability and future-proofing.

The ASSD system(s) should be:

1) Developed using technologies with a clear long-term future.

2) Designed in such a way as to maximise the potential to change system configuration in response to changing requirements (the Personalisation Agenda and beyond), especially those which are externally imposed – new central government requirements, etc. The system(s) should also be placed to cope with changes driven by the ongoing evolution of best practice. This should include capture of types of data not previously considered for capture.

3) Designed so they fit with integration technologies such as SharePoint.

4) Flexible enough to support integration with partner organisations at the pace and in the ways they are ready for.

Potential software supplier(s) should provide and clearly articulate:

1) A strategic vision of the future of their product(s) in the marketplace – both their existing and future products.

2) A clear ‘road map’ of planned system development over the medium-term, making reference to major drivers in the statutory, regulatory, business, technological, etc. environments.

3) Detailed plans for content of next version/release of their software.

5.20 Business Continuity & Data Recovery Potential system suppliers should define how their solutions will achieve LB Barnet’s requirements for Business Continuity & Data Recovery.

It would be desirable for system suppliers to provide Business Continuity & Data Recovery facilities as part of the maintenance contract.

5.21 Complete and adequate systems documentation, kept up-to-date The Council requires documentation that supports its implementation and day-to-day use of each IT system, without the need for constant reference back to the system supplier (or support partner). Our requirements are explained at greater length in ‘Product Description F.17: System Documentation’ in Appendix B – High-level Product Descriptions for ASSD system requirements.

5.22 Test and training databases The system software should be supplied in sufficient copies and/or appropriate configuration to allow a number of environments in addition to Live/Production – at a minimum, 1 Test and 1 Training environment will be required.

Preferably, test and training environments should be pre-populated with sample data on delivery, to enable testing and trainers’ review to begin with minimal delay.



5.23 Archiving A full or partial archiving facility is required, configurable by LB Barnet

The system(s) should also have an auto-delete facility on archived records, by date, dependent on retention policy.



6 Detailed Functionality Requirements LB Barnet’s specific requirements are laid out as a series of required ‘products’; the hierarchy and interrelationships between these are analysed in Appendix A – Product Breakdown Structure. The ‘products’ are explained in individual ‘Product Descriptions’, and broken down into component features; each component feature being ranked as Essential, Desirable or Nice-to-have. Reference is made, wherever appropriate, to existing and/or expected integrations / Interfaces with other systems (both LB Barnet systems and external systems) such as Wisdom, SAP and CM2000 CallConfirmLive!.

6.1 Case Management Requirements Please refer to ‘Appendix B – High-level Product Descriptions for ASSD system requirements’ (Product Descriptions coded ‘A’) for details.

6.2 Performance Management Requirements The system(s) must be able to extract all management Information reports required, both statutory returns and reports to meet internal information requirements. Please refer to ‘Appendix B – High-level Product Descriptions for ASSD system requirements’ (Product Descriptions coded ‘B’) for details.

6.2.1 Statutory returnsThe current Statutory Returns are listed in Appendix C – List of current statutory returns and Performance Indicators (as at August 2009)

6.2.2 PAF IndicatorsThe current Performance Assessment Framework (PAF) indicators are listed in Appendix C – List of current statutory returns and Performance Indicators (as at August 2009)

6.3 Strategic Commissioning Requirements The aim of the Strategic Commissioning function at LB Barnet is to provide the best possible health and social care provision with the best use of resources through an all encompassing approach. This is achieved through these methods

1) Understand needs and aspirations within the context of national and local priorities

2) Identify and agree outcomes for individuals, families and communities

3) Design and deliver service provision to meet outcomes

4) Manage performance

With the Personalisation Agenda, the Strategic Commissioning function has to develop a consumer-led market.

Strategic Commissioning’s system requirements are outlined in Product Description C in ‘Appendix B – High-level Product Descriptions for ASSD system requirements’.



6.4 Contract Management Requirements It is vitally important to have a single, comprehensive register of ASS contracts with service providers – currently there are c.500 spot providers to LB Barnet and a few block contracts. LB Barnet is currently re-tendering its homecare contracts – an annual spend of c. £13m p.a.

However, Contract Management requires more than simply a register. The system should provide a full range of information with which to manage contracts and provider relationships, including approval and suspension of providers. Tools would include

Various monitoring reports

Links to E-documents

Contract Management chronology

Provider approval and suspension flags

Please refer to ‘Appendix B – High-level Product Descriptions for ASSD system requirements’ (Product Descriptions coded ‘D’) for details.

N.B. ASSD will not need ASS-specific E-procurement provided the corporate SAP CRM is developed; in which case ASSD will use the corporate solution (see also section above).

6.5 Financial Management Requirements (processing, reporting, analysis & monitoring; operational & strategic)The Council’s Financial Management requirements include processing, reporting, analysis and monitoring, at both the operational and strategic levels.

Please refer to ‘Appendix B – High-level Product Descriptions for ASSD system requirements’ (Product Descriptions coded ‘E’) for details.

N.B. Invoice Processing is not part of Finance at LB Barnet – see notes at above.

The financial system(s) solution in totality needs to be complete, accurate, timely and seamless

- no discontinuity

- no re-keying and/or unnecessary off-system data manipulation

- intelligent integrated management information reporting incorporating both financial and non-financial data

6.5.1 Housekeeping and synchronisation of account coding structure SAP R/3, as the corporate financial system, is ‘lead’ on the account coding structure and the values of account code elements (cost centres, etc.) which are valid at any time, individually and in what combinations.

This structure should be reflected in the ASS system(s) and regularly synchronised with SAP.

There will need to be robust rules around the maintenance of account codes, especially when values are taken out of use (e.g. cost centre closes down), to ensure all ‘open’ financial records (cost commitments, client charges, etc.) and



financial transactions (payables, billing, etc.) use only valid account codes. The ASS system(s) should incorporate rules to prevent the use of invalid account codes (even where a code may previously have been valid), so as to avoid problems with financial processing and reporting. (One such rule might be to automatically close all cost records using an ‘old’ cost centre, the end date being the effective date from when the cost centre has been taken out of use.)

6.5.2 Systems reconciliationsFinancial information held on ASS system(s) and the corporate SAP system should be easily, clearly and fully reconcilable whenever required. The fundamental requirement is to reconcile ‘actuals’ (both expenditure and income), but it is also highly desirable to reconcile year-end forecast figures (expenditure commitments and income projections).

All reconciliations should be available at various levels of granularity, down to client and transaction level.

6.5.3 Budget monitoring and integrated financial and management information reportingWhilst LB Barnet is not presently minded to be prescriptive about which system(s) should be used for budget monitoring, it would be preferable for SAP to contain all the key data and to be the primary data source for budget monitoring and financial modelling. Additional, supporting information may well come from other system or non-system sources. Reporting should therefore be flexible and allow controlled, auditable, human intervention by specialist staff to ‘factor in’ other information, predictions, judgements, etc. not held in the core system(s).

Budget monitoring should be possible down to client level.

It should be possible to associate financial with non-financial information (e.g. activity, demographics) and report on this in an intelligent, meaningful way.



7 Wisdom – Electronic Document and Records Management System (EDRMS)

7.1 EDRMS - corporate ASSD has been one of 5 early-adopters of the Council’s EDRMS system, Wisdom7.

7.2 EDRMS and the care management system The basic principle should be that the care management system is the principal data source and the main area around which work is flowed. Wisdom is solely for record management. Only information that constitutes a record, i.e. data that is shared in a specific format between 2 parties at a specific point in time, should be stored in the EDRMS.

Navigation between electronic data and scanned documents should be seamless and intuitive, using Web-browser navigation methods (hyperlinks, etc.). The current integration is straightforward in that clients in the care management system (SWIFT) are linked to client files in Wisdom. Moving forward, the integration should be more comprehensive to allow for more efficient navigation, e.g. to document or folder level for clients. Also changes to clients in the care management system should be more consistently and more quickly reflected in Wisdom, e.g. ending a client. Furthermore, there must be a 2-way information flow, not unidirectional as at present (i.e. SWIFT-to-Wisdom only).

7 ASSD and the Children’s Service were the first to implement Wisdom in their Service areas. Since then Housing Needs & Resources, Environmental Health and HR have successfully implemented Wisdom as their Records Management System.



8 LB Barnet Technical Specifications8.1 Technical Landscape

LB Barnet will be undergoing significant IT technical changes over the next few years so need to be fairly open in our requirements. However we can say that currently we use the following:

Desktop - Windows XP, MS Office 2003, IE 6 moving to IE 7. We run Symantec Antivirus on the desktop.

Thin Client - Citrix

Printing - Windows printing to Safecom queues to Xerox MFDs although any Windows printers should be available

Servers - Windows Server 2003

Database - MS SQL (2005) or Oracle (10g) preferred

Web - IIS, ability to use SSL pages.

Reporting - Business Objects XI

Network - Cisco

Remote working - using VPN and RSA tokens

Mobile working - Tablets / laptops using desktop standards and Checkpoint encryption

Moving forward we would want to look at

Virtualisation of servers

Using SAN technology for data storage

8.2 Technical Requirements for application systems

Please see the attached (embedded) document (double-click to open) for LB Barnet’s indicative/generic technical requirements for application systems, under the following headings:

Key system requirements

Support & Service Level requirements

Data conversion, implementation & acceptance of the system



9 ConclusionsLB Barnet’s understanding of its IT system needs for Adult Social Services has moved on significantly since the contract was agreed to procure Liquidlogic’s PROTOCOL eSAP. Our requirements are now

Wider

Deeper

More customer-driven

There are extensive detailed requirements and challenging overall features required. We therefore need to determine which of these Liquidlogic, with its partners, can meet, at what cost and when, and what Liquidlogic and partners cannot meet.

10 Next StepsSerco are invited to comment on how the Liquidlogic offering can meet the requirements set out in this document, specifically providing a gap analysis and approximate costings of any functions or features which would need to be developed above and beyond the standard Liquidlogic offering. Estimated delivery timescales should also be indicated, as well as overall costs (capital and revenue).

So can we have all that

then?

When can we have it?

How much is it going to

cost?

How much is it going to costup-front?

What are the running costs?

What are the options?

Is it all in yourcore

product(s)?

When can we start

testing?When can we start using it for real?

Serco are requested to please provide a response within 2 weeks of the date of the covering letter to this document.



Appendices

Appendix A – Product Breakdown Structure

Please see separate document embedded here



Appendix B – High-level Product Descriptions for ASSD system requirements

Please see the attached (embedded) document (double-click to open).

It is most likely that these requirements will go through more iterations of refinement and prioritisation, but they are a broadly comprehensive and accurate picture of ASSD’s perceived requirements as at September 2009.



Appendix C – List of current statutory returns and Performance Indicators (as at August 2009)Statutory returns as at August 20091. Referrals, assessments and packages of care (RAP)2. Adult Social Care Combined Activity Return (ASC-CAR)3. Expenditure and unit costs (PSS EX1) return4. Vulnerable adults return 2009-105. Social services staffing return 2009-106. Self-Assessment Survey (SAS)7. Grant Funded Survey (GFS1)8. Capturing Regulatory Information at Local Level (CRILL) 9. User Surveys – Homecare, Voluntary Carers10. SDA910 Deaf/Hard of Hearing return

PAF indicators as at August 2009

1: Improving health and emotional well being 1.2 NI 124 People with a long-term condition supported to be

independent and in control of their condition1.2 NI 125** Achieving independence through rehabilitation /

intermediate care (OA)1.2 D40 Reviews

1.3 NI 131 Delayed Transfers of Care (NHS & ASSD, Acute & Non-acute)The indicator is an index per 100,000 population aged 18+Figures in brackets denotes average weekly number of patients delayed

1.3 D41 Delayed Transfers of Care (NHS & ASSD, Acute)An index per 100,000 population aged 65+Average weekly number of patients is in brackets

1.3 Local* LB Barnet1

Delayed Transfers of Care (Acute) attributable to Social ServicesAverage weekly number of patients delayed

2: Improved quality of life2.1 NI 136 People supported to live independently through social

services (all adults)2.1 C29 Helped to Live at Home - PSI

2.1 C30 Helped to Live at Home - LD

2.1 C31 Helped to Live at Home - MH

2.1 C32 Helped to Live at Home - OA

2.1 C28 Intensive home care

2.1 Local* LB Number of DPs in lieu of intensive home care



Barnet2


Number of vulnerable people 18+ who have received Telecare in the year

2.1 D54 % of equipment & adaptations < 7 days2.1 NI 135* Services for Carers (inc information)

2.1 C62 Services for Carers

2.1 NI 141* %age of vulnerable people achieving independent living

(Supporting People KPI 2)2.1 NI 142 %age of vulnerable people who are supported to maintain

independent living (Supporting People KPI 1)

3: Making a positive contribution

4: Increased choice & control4.1 NI 132* Timeliness of social care assessment (all ages)

4.1 D55 Assessments start<2 days, end <28 days (OA)

4.1 NI 133 was D56

Timeliness of social care packages following assessment (all ages 2009/10)

4.6 C72 Admissions - OA

4.6 C73 Admissions - YA

4.5 D39 Statement of needs

4.1 E82 Assessments leading to service

4.7 NI 130 Self-directed support (DPs + IBs). Brackets denote number of service users.

4.7 C51 Direct payments


Number of Mental Health Direct Payments

4.7 NI 145 LD in settled accommodation (Assessed/Reviewed Clients)4.7 NI 145 LB

BarnetLD in settled accommodation (All Clients)

4.7 NI 149** MH in settled accommodation

4.7 Local*£ LB Barnet5

Number moved from res care to independent accommodation (accumulative)

5: Freedom from discrimination & harassment5.3 E47 Ethnicity of older people receiving an assessment



5.3 E48 Ethnicity of older people receiving a service after an assessment

5.3 KTI Percentage of missing ethnicity data

6: Economic well-being6.4 NI 146** LD in paid employment (Assessed/Reviewed Clients)

6.4 NI 146** LB Barnet

LD in paid employment (All Clients)

6.4 NI 150 MH in paid employment

7: Maintaining personal dignity & respect7.4 D37 Availability of single rooms

8: Leadership

9: Commissioning & Resources9.2 B11 Intensive home care

9.2 B12 Cost of intensive social care

9.2 B17 Unit cost of home care



Appendix D – Choice And Independence – A Vision For Adult Social Services

Please see separate document, embedded here

Appendix E – Adult Social Services Business Plan 2009-10


Appendix F – Online Resource system specification


Appendix G – Care Model Development Project

Please see separate consultation paper, embedded here



Appendix H – LB Barnet Address Standards Background informationThe Unique Property Reference Number (UPRN) is the key reference field. Every property in England & Wales is allocated a UPRN. Blocks of UPRNs are allocated nationally to local authorities; when a local authority is going to run out of its allocated block of numbers, it can apply for another block.

The Local Land and Property Gazetteer (LLPG) is managed by LB Barnet, and this feeds into the National Land and Property Gazetteer (NLPG), which is managed by Intelligent Addressing, on behalf of all local authorities. Out-of-borough addresses will need the NLPG address. LB Barnet has off-line access to the NLPG. It is possible to purchase a direct link to the NLPG but LB Barnet does not currently have this.

In LB Barnet, the LLPG is amalgamated with the Local Street Gazetteer (LSG). Each street has a Unique Street Reference Number (USRN).

Data translation in and out of the Gazetteers is by files in the UK-standard file format DTF8 (currently DTF 7.4). A daily DTF export of LLPG updates is fed in to the NLPG.

LB Barnet uses ACOLAID software9 to manage the LLPG and LSG.

Elements of an address record (mandatory fields in bold)1) Postcode2) County (in-borough addresses are London, Middlesex or Hertfordshire)

3) Town4) Locality (as this cannot be geographically defined, it is not used as part of the main

structure)

5) Street (incl. USRN)

6) Primary Addressable Object Name (PAON)a) PAON number fieldb) PAON name fieldc) PAON range field(A combination of the name field with 1 of the other 2 may be used)

7) Secondary Addressable Object Name (SAON)a) SAON number fieldb) SAON name fieldc) SAON range field(A combination of the name field with 1 of the other 2 may be used)

There is a ‘parent/child’ relationship between the PAON and the SAON.

There are naming conventions for each field, e.g. ‘Ground Floor Flat’ not ‘GFF’.

8) Spatial coordinates (‘Easting & Northing’10)

8 Data Transfer Format9 From IDOX Group. ACOLAID is also used to manage the Council’s street naming and numbering function, and to manage local land charges. ACOLAID is used by Planning Services, Environmental Health, Trading Standards and Licensing.10 This is an Ordnance Survey standard



Data migration/load and maintenanceLoading and maintaining address data in ASSD system(s) should be from the relevant Gazetteer, and as such the ASSD systems(s) must support import of files in DTF format.

Initial migration/load of LLPG / NLPG data into a new database is quite flexible – we can pick and choose the elements to be loaded.

Regular maintenance needs to be well planned and precisely defined, to avoid problems.

LLPG updates are 1 of 3 types:i. Completely new recordii. ‘Delete’ – actually is historicisediii. Update (change) existing record

Possible ASSD future uses for mapping data Spatial mapping of relevant information could be used for ASSD purposes such as

planning visits.

The NLPG could be analysed to show clustering of out-of-borough customers on a map.

Technical specification and further readingPlease see separate technical specification for ACOLAID Land and Property Gazetteer

Variables, embedded here

Please also find below a link to the “library” page of the NLPG website, which contains a number of documents that may be of use:http://www.nlpg.org.uk/nlpg/link.htm?nwid=56

Requirements for ASSD system(s)1. The ASSD system(s) must be capable of holding the UPRN at a minimum.

2. The ASSD system(s) should preferably be capable of holding at least the 8 elements of an address listed above.

3. The ASSD system(s) should preferably be capable of accepting data in DTF format.


http://www.nlpg.org.uk/nlpg/link.htm?nwid=56


Document ControlRevision History

Version Live/Draft Revision date Comments0.1 Draft 11 September 2009 1st draft (issued for LB Barnet management

review)0.2 Draft 22 September 2009 2nd draft following initial comments and check

through against deliverables stated in Project Brief

0.3 Draft 24 September 2009 3rd draft following LBB management review in Workshop 23/9/09. Includes re-ordering of sections.

0.4 Draft 25-28 September 2009

4th draft incorporating comments and information from LBB GIS Manager, LBB Head of Finance and NHS Barnet, and additional feedback from other LBB managers.

0.5 Draft 28-29 September 2009

5th draft incorporating expanded technical specification (section 8) and reflecting final feedback from LBB management. Specific changes, some substantial, in (sub-)sections 3.1.2, 4.2.1, 4.2.2, 5.1, 5.2, 5.4, 5.5.1, 5.7.1, 5.8, 5.11, 5.15, 5.17, 7, 9. Added new sub-section 3.1.8. Noted comments as to whether including section 9 is appropriate for the purposes of this specific document. The document now includes draft Conclusions and Next Steps (in reversed order) and a draft Summary. Also added some extra statements to sections 5.13 (Reporting/Outputs) and 5.15 (Meets statutory, etc. requirements), and a qualifying statement to Appendix B.Appendix B detailed Product Descriptions also updated in parts.

0.6 Draft 30 September 2009 6th and final ASSD draft following final feedback and advice from David Court & Mathew Kendall.Deleted sections 7.3, 7.4 & 9; deleted previously struck-through text in sections 5.17.5 & 5.17.6; deleted redundant comment at 5.9.Some reformatting to better align text with headings, and page break for Section 3.

1.0 Live 30/10/2009 MK 1st Live version Introductory para’s slightly amended



Reviewers

Name RoleKate Kennally Deputy Director, Adult Social Services - Strategic Commissioning and

TransformationGlynnis Joffe Assistant Director, Adult Social Services - Care Services Delivery

Mathew Kendall Assistant Director, Performance and Supply Management, ASSD

Andrew Filby Head of Finance, ASSD

Nigel Love Service Manager, Community, Older Adults Services, ASSD

Senel Arkut Service Manager, Hospitals and Rehabilitation, Older Adults Services, ASSD

Marie Bailey Service Manager, Physical and Sensory Impairment, ASSD

Amanda Jackson Service Manager, Learning Disabilities Social Care, ASSD

Maggie Goff Social Care Development Manager, Mental Health Services, Care Services Delivery, ASSD

Eryl Davies Head of Strategic Commissioning, Strategic Commissioning and Transformation, ASSD

Ed Gowan Choice and Independence Programme Manager, Strategic Commissioning and Transformation, ASSD

Tom Pyne Head of Supply Management, ASSD

Ian Goode Interim Service Manager, Business Improvement Team, Performance and Supply Management, ASSD

Mike Kallas Swift Support Team Manager, Business Systems & Partnerships, Information Systems

Steve Brooks EDRMS Programme Manager, Shared Services Management (Wisdom, also Children’s Service Financials)

David Court Business Systems Manager, Performance and Supply Management, ASSD

Jenny Coombs Assistant Director, Shared Services

Anjum Fareed Head of Performance, NHS Barnet

Tina Lukow Head of Information, NHS Barnet

Approvals

Name Role Signature / Initials Date



Name Role Signature / Initials Date

Authorisation

Name Role Signature / Initials DateMathew Kendall Assistant Director,

Performance and Supply Management, ASSD

Kylton Trim Head of Information Systems
