integrated children’s system minimum compliance criteria

Integrated Children’s SystemMinimum Compliance Criteria

January 2007

Version 2.1

ICS Minimum Compliance Criteria version 2.1 (January 2007) of 34

Introduction

This document has been prepared to define a minimum set of criteria to assess the ICS compliance of local authorities at go live. The basis for these compliance criteria are the ICS Business Requirements issued to local authorities in LAC(2005)3.

The objective of this exercise was to define a set of criteria that are objective, robust, and traceable to published source documentation. This will enable a fair and objective assessment of local system compliance by local authorities, ICS product suppliers, and DfES. Each criterion is derived from at least one of the following sources.

Children’s Social Services Core Information requirements November 2003 (see www.everychildmatters.gov.uk/resources-and-practice/IG00009)

o Data Model v3.1

o Process Model v3.1

o Entity relationship diagram v3.1

o Process flow diagrams v3.1

Briefing Papers 1-5 (November 2000-September 2002)

Briefing Papers 6-8 (October 2005)

www.everychildmatters.gov.uk/socialcare/integratedchildrenssystem/briefingpapers

Content of the 26 exemplars (2002)

www.everychildmatters.gov.uk/socialcare/integratedchildrenssystem/resources/exemplars

LAC (2005) 3 (March 2005)

www.everychildmatters.gov.uk/socialcare/integratedchildrenssystem/about

The compliance criteria are set out below as a table, containing the following information:

- Business Requirement: The business requirements as defined in LAC(2005)3. For the sake of familiarity and ease of use, we have retained the identification codes used in the business requirement questionnaire issued to each local authority during the 2006 ICS Readiness Assessment. Blue text in D48.1 – D50 indicates clarification added after the publication of LAC(2005)3, but which the readiness review requested local authorities to respond on (apart from 48.3, which provides extra clarification added in this document). These were not specified in the


http://www.everychildmatters.gov.uk/socialcare/integratedchildrenssystem/about

http://www.everychildmatters.gov.uk/socialcare/integratedchildrenssystem/resources/exemplars

http://www.everychildmatters.gov.uk/socialcare/integratedchildrenssystem/briefingpapers

http://www.everychildmatters.gov.uk/resources-and-practice/IG00009

LAC(2005)3 circular, but the supporting information about ICS to which that document refers (in particular the consultation document issued in December 2002) made clear that the exemplars are designed to work within an electronic information system which supports single data entry of information. That is, information once entered into the system will transfer from one record to another. There is a high risk that not specifying this functionality will make the system extremely difficult to use.

- Sub-Requirement: A breakdown of each requirement into its logical sub-requirements to facilitate the clear assessment of all aspects of the requirement.

- Criteria: Provides further information on the intent behind each requirement and more specific information on what is necessary in meeting the requirement. This section also indicates the level of compliance on the requirement needed for full go live. These compliance levels are defined in the following table.

Must Have Essential for full go live

Should Have This requirement should be met, but is a lower priority than “must have”. There may be some limited flexibility around the implementation dates for these requirements, but a plan must be in place when the authority goes live with ICS, setting out the timescale for delivery of any outstanding “should have” requirements.

Desirable Not in the original requirements and therefore not a condition for compliance at go live. However, DfES wants local authorities’ systems to be able to do this.

Nice to Have Not essential for go live

All requirements are MUST HAVE unless otherwise stated.


ICS Minimum Compliance Criteria by Business Requirement

Business Requirement Sub Requirement(s) Criteria

D28: The recording of work with children in need and their families using the ICS conceptual framework is implemented as an IT based system.

NA An IT based system MUST be in place: without this, the LA will fail other requirements.

ICS MUST be the system for core children’s social services responsibilities of the local authority. The requirements can be met by different components (e.g. one supplier’s module sitting on another’s database), as long as together they provide a whole system.

(NB: Single data entry is fundamental to the system.

Implicit in the business requirement was that the IT system should have single data entry, otherwise it will not support practitioners effectively and will not work as intended).

D29: Each front-line staff member has dedicated access to a computer as and when necessary to undertake case recording and case management.

NA (NB: This does not automatically mean a 1:1 ratio – the key is availability as and when needed).



D30: Each member of staff who needs to use the ICS system has the necessary IT skills.

NA LAs MUST have assessed training needs and completed the necessary training.

D31: Each child’s record includes a unique identifier and has provision for recording similar identifiers used in other applications as is appropriate to support integrated working across agencies.

Each child’s record includes a unique identifier

and has provision for recording similar identifiers used in other applications as is appropriate to support integrated working across agencies.

The identifier MUST be unique to that child within ICS within the LA.

The system MUST also be able to record each child’s NHS number.

The system SHOULD HAVE the capability of recording at least three other identifiers.

The system SHOULD HAVE the capacity for the other identifiers to include the home office registration number, court case number and unique pupil number in cases where these apply.

All fields containing identifiers MUST be able to be labelled with the description of that identifier

Although not stated in the requirement, it is DESIRABLE to be able to search on the other identifiers.

D32: Information required for each of the key processes for responding to children in need (contact, referral, assessment, plan, intervention and review) is

Information required for each of the key processes for responding to children in need is

This refers to the content (data fields) of the exemplars. All the information on the exemplars MUST be capable of being collected on the system (though there is flexibility in the format, especially input format).



held electronically using the content of the appropriate ICS exemplar. The input and output format for this information is fit for purpose.

held electronically using the content of the appropriate ICS exemplar:

“Information Gathering”:

Contact = Contact Record

Referral = Referral and Information Record

Other information gathering =

- Placement Information Record

- Chronology

- Closure Record

Assessment:

- Initial Assessment Record

- CP1 Strategy – Record of Strategy Discussion

All the exemplars’ content MUST be capable of being collected on the system, including maintenance of the separation of the different age bands in the cases of the Core Assessment Records (all age bands) and the Assessment and Progress Records (all age bands).

The system SHOULD include the capability to collect the tick boxes in the health; education; emotional and behavioural development and self-care skills; identity and social presentation; family and social relationships; and family and environmental factors sections of the Core Assessment forms and the equivalent tick boxes on the Assessment and Progress Records.

The structure of Plans; of plans within Review documents; and plans within the Closure Record, Initial Assessment Record, CP2 – Record of Outcome of s47 enquiries and CP3 – Initial Child Protection Conference Report is to be maintained. This means that the headings in the tables such as Health Development Needs in the Child or Young Person in Need Review MUST be maintained and the progress against identified needs be able to be followed through the table.

The actions and outcomes MUST be captured under the seven child development headings in the Assessment Framework: Health; Education; Emotional and behavioural development; Identity; Family and social relationships; Social presentation; Self care skills.

The input and output format of the information entered



- CP2 – Record of Outcome of s47 enquiries

- CP3 – Initial Child Protection Conference Report

- Core Assessment Records (six exemplars each covering a different age band)

- Assessment and Progress Record (four exemplars each covering a different age band).

Plan:

- Child or Young Person’s Plan

- Child or Young Person’s Care Plan

- Child or Young Person’s Adoption Plan

SHOULD support the process of: recording, summarising, analysing and decision making.

Local authorities SHOULD take care to commission a system that provides fit for purpose outputs. "Fit for purpose" means the outputs provide sensible information facilitating the job the user needs to do (e.g. via printout or tablet PC). As a guideline, if the document is self-explanatory, it is likely to be satisfactory.



- Pathway Plan

Intervention: this is covered by the exemplars under Plan and Review

Review:

- Child or Young Person in Need Review

- Child or Young Person’s Child Protection Review

- Child or Young Person’s Looked After Review

The input and output format for this information is fit for purpose.

D33: Having entered information, staff are able to output (to print or screen as appropriate) information in a

Having entered information, staff are able to output (to print or screen

The output format of information entered through the key processes MUST be convenient and concise, in a lay out that follows a logical flow and is user-friendly.

The system MUST be able to output information to print or



convenient and concise format. as appropriate) information

in a convenient and concise format.

screen in a convenient and concise format.

The system SHOULD be able to output information to print AND screen in a convenient and concise format.

D34: The database containing all the basic information on children in need is searchable so that links can be made for the purposes of safeguarding children. These include in both search directions: adult – child; child – address; child – family; child – school; child – placement; child – need category; child – service.

The database containing all the basic information on children in need is searchable so that links can be made for the purposes of safeguarding children. These include in both search directions:

adult – child;

child – address;

child – family;

child – school;

child – placement;

child – need category;

As a minimum, the following searches MUST be possible:

Input : Adult or Address or Family or Placement

Return: Child

Input: Child

Return: Adult or Address or Family or Placement

(NB: instead of defining a family as an entity, it is acceptable to meet this search requirement by searching on surname and / or address. For example:

Input: Surname

Return: All records with that surname

Input: Address

Return: All residents known to the ICS system at that address.)

The following searches SHOULD also be possible:

Input: School or Need Category or Service

Return: Child



child – service. Input: Child

Return: School or Need Category or Service

A search SHOULD be able to look for more than one data field (e.g. filtering on a minimum of two attributes).

The outputs from the search function MUST be displayed on screen through the ICS system and include enough detail for the query to be followed up (e.g. provide a reference if it is not possible to “drill down into” the search return)

Searches MUST not be delivered through the finance system. Finance systems will only provide information on services that local authority social care services are paying for, and would miss important elements of the care plan.

The minimum attributes in the system for each entity, though not necessarily all returned by searching, SHOULD be those in the logical data model:

Family – p87 (NB – see note above under minimum searches).

Address – p12

Adult – p36 under “Adult Service User”

Child – p54 under “Child Service User”

Service –p115 under “Provision of Service” through to p125. Here the list of service types is only illustrative and the LA will need to determine, but should be mindful of statistical returns. The system will need to force use of consistent terminology.



Placement - p115 under “provision of service” through to p125. Here the list of service types is only illustrative and the LA will need to determine, but should be mindful of statistical returns. The system will need to force use of consistent terminology.

Need category – p154 under “Service User Need Category”. The system will need to force use of consistent terminology. The LA has flexibility to define its own list but the data model User Need Type level provides a guide to the level of information. It is a requirement that the list of service types includes the CiN codes on p156 of the data model, and ideally (DESIRABLE) more detailed types beneath these.

School – p82 “external Body”

D35: Key adults in children’s lives are recorded against their relationship with each child so that contacts are facilitated by generating letters or messages for making appointments or convening conferences and reviews.

Key adults in children’s lives are recorded against their relationship with each child

so that contacts are facilitated by generating letters or messages for making appointments or convening

The system MUST HAVE the ability to record a child’s relationship with key adults (using the entity definitions under External Person on p83 and Service User Relationship under p170 of the Logical Data Model). NB there is no minimum set of relationships prescribed centrally. This is for the LA to define, but the system MUST force the use of consistent terminology.

(NB:

The Referral & Information Record exemplar asks for ‘relationship to child’ information in the following sections: child/young person’s main carers; other household members; significant family members who are not members of the child’s



conferences and reviews.

household.

The fields required for each adult are as per the exemplars (i.e. forename, surname, relationship to child/young person, address and postcode, telephone number, first language, ethnicity) and the data format is defined in the Data Model).

It is DESIRABLE for the relationships to be searchable.

At a minimum the user MUST be able to type in the name of a key adult for a particular child and view the contact details to facilitate communication (e.g. invite GP or professional to a child protection conference). It is acceptable for the contact details to come via an interface to another LA system.

Auto creating letters or messages to relevant / key personnel to arrange interviews or convene conferences or reviews, using relationship data is NICE TO HAVE. Messages include letter, e-mail, telephone.

D36: Front-line staff and managers are able to see on a computer screen a list of children for whom they currently have case responsibility. Managers are able to determine which cases are unallocated.

Front-line staff and managers are able to see on a computer screen a list of children for whom they currently have case responsibility.

Users MUST be able to display to screen a list of all the children for whose cases they have accountability (whether front -line staff or managerial). A pre-defined report generating this information is acceptable.

Accountable users (e.g. the leader / manager of the team or service concerned) MUST be able to see a list of unallocated cases.

It is unacceptable to provide only aggregate numbers of the



Managers are able to determine which cases are unallocated.

unallocated cases. The accountable user MUST be able to know which cases are unallocated. A pre-defined report generating this information is acceptable.

In both cases, minimum data to be shown on screen MUST be sufficient to identify the child uniquely within ICS.

D37: Front-line staff are able to see on a computer screen basic summary information (name, address, case number, legal status (basis for being looked after/supervision/other orders), registrations, family members, relevant adults (including professionals) and significant others with contact details etc.) on each child for whom they have responsibility.

Front-line staff are able to see on a computer screen basic summary information

name,

address,

case number,

legal status (basis for being looked after/ supervision/other orders),

registrations,

family members,

relevant adults (including

The system MUST be able to display basic case information. The content specified in the business requirement MUST be easily accessible from a summary screen (i.e. it is not essential for all the summary content to be displayed on the same single screen but it must be accessible for example through tabs, hyperlinks or other simple screen navigation methods).

(NB: The data listed in the business requirement is the minimum requirement and summary formats will vary between LAs).

The system MUST force use of consistent terminology for possible registration and legal statuses.

Registration MUST include: child protection*, disability and other;

Legal Status MUST have as a minimum the list of types in the data model page 100 and “other”. The legal status “freed for adoption” no longer applies and does not need to be in the list, but the following should be added: “Status: Section 21 Adoption and Children Act 2002. Service provided: Placement Order”.



professionals)

and significant others with contact details etc.

on each child for whom they have responsibility.

The system SHOULD HAVE an audit trail capability to show who updated the information.

(* NB: By 1 April 2008, references to “child protection register” should be replaced by “child is subject to a child protection plan”).

D38: For each child it is possible to list the services (including individual foster/residential care) received by the child and/or the child’s family both currently and historically. And conversely, for each service (including foster or residential placement) to list the children currently and historically served.

For each child it is possible to list the services (including

individual foster/

residential care)

received by

the child and/or members of the child’s family or household.

both

currently and

historically.

The whole of this requirement is SHOULD HAVE.

Search Input: Child

Search Return

All services received (current & historical) by the child.

All services received (current & historical) by the family members/household of which the child is part.

(NB: Family is defined on page 87 of the Logical Data Model. As an alternative to defining family entities for this requirement, it is acceptable to provide lists of services to the same surname or the same address).

Search Input: Service (including Fostering, residential care,



And conversely, for each service (including

foster or

residential placement)

to list the children

currently and

historically served.

CAMHS and education)

Search Return: All children who received the service (now and historical)

Although only two kinds of service are listed in the requirement, this is driving at a whole range of services. It is for the LA to define this list of services and the system SHOULD force consistent use of terminology. The list SHOULD be at service type level not at the higher service category level (e.g. generic “residential care”) and should also include CAMHS and education services. (The data model pp116-119 is an example of the levels to use, but its content is not comprehensive for children’s services).

Allocated services SHOULD be recorded taking the information from the needs tables in the plans in the exemplars.

Services that have actually been received by the child SHOULD be recorded on the system. It is not acceptable to record services allocated as a proxy for services received.

If some information is held on a different system, there SHOULD be an automatic interface from ICS so that there is no need for the user to carry out a separate operation on that different system.

There is no requirement to enter historic data prior to the “Go Live” date for the functionality for this Business Requirement.



D39: Outcome information on children is recorded so that progress for individual children can be traced and aggregated for outputting performance assessment information. This includes educational attainment, health status, offending, placement stability, protection from abuse and neglect.

Outcome information on children is recorded so that progress for individual children can be traced and aggregated for outputting performance assessment information.

This includes

educational attainment,

health status,

offending,

placement stability,

protection from abuse and neglect.

The ICS system MUST hold the relevant data constituting outcome information for children.

For this requirement, recording information on individual children’s progress MUST be a means for: (1) provision of aggregated data by the local authority; (2) for users to be able to view at an individual child level relevant outcome information for the cases for which they are accountable.

Aggregate outcome reporting

The system MUST be able to provide aggregated performance assessment information to support the relevant statistical returns required by the Government.

Recording of CIN codes is a MUST HAVE

The system MUST store all the information necessary for completion of the relevant returns to DfES. The current returns relevant to ICS are:

CPR3 – Assessments and Young People on Child Protection Registers

OC2 – outcome indicators for looked after children

SSDA903 – Children Looked After (including adoptions and care leavers).

ALL the information stored on the above forms is a MUST HAVE for ICS.

(NB: The following website contains the guidance for all the LA



social services returns: http://www.dfes.gov.uk/datastats1/guidelines/children/returns.shtml

It includes the CIN census and user experience survey which are not current but it is useful to refer to the CIN guidance for the CIN codes and for the future DfES hopes to introduce something in its place which will ask for similar information about the children known to children’s services. This means that with the exception of the CIN codes on the Referral and Information Form, any information additional to the social services returns that is in the CIN census is a "NICE TO HAVE").

D40: When the name of an adult, including aliases, previous names, spelling variations, is entered into the information system supporting the Integrated Children’s System, the names of all the children with a recorded association with that adult are identified in a printable output.

When the name of an adult, including

aliases,

previous names,

spelling variations,

is entered into the information system supporting the Integrated Children’s System, the names of all the children with a recorded association with that

The Logical Data Model defines any interaction between two people as a relationship. In this context:

“association” MUST be recorded in the same way as relationship in D35.

The system MUST allow the LA to define enough types of relationship to meet the intentions of this requirement, which might include relationships such as: abuser/abused child, or criminal/accessory to crime

The system MUST force use of consistent terminology for the types of relationships.

The system MUST support searching on and identification of aliases and previous names.

The system MUST support identification of the names of


http://www.dfes.gov.uk/datastats1/guidelines/children/returns.shtml


adult are identified

in a printable output.

children with a recorded association with an entered adult’s name.

The system SHOULD support spelling variations on names on the search function.

The ability to print a report of the names of children with a recorded association with a specific adult is a NICE TO HAVE.

D41: Every time there is an allegation that a child is being sexually abused, there is a searchable record created on the child’s ICS record indicating whether or not the allegation was reported to the police. The record includes the date the decision was made and, if the decision was to refer, the date the information was passed on. The record also includes in the case of each allegation, the reason why or why not a referral was made. The system supports a retrospective audit focusing on the number of allegations not referred to the police and the justifying

Every time there is an allegation that a child is being sexually abused, there is a searchable record created on the child’s ICS record

indicating whether or not the allegation was reported to the police.

The record includes

the date the decision was made and,

if the decision

The system MUST record information within the child record for allegations of sexual abuse. The record MUST indicate whether there has been a sexual abuse allegation. Fields MUST include:

whether the allegation was reported to the police (Yes or No),

the date this decision was made,

the reason for the decision and

if ‘yes’ the date the information was passed to police).

The reason why an allegation was or was not referred to the police may be in a free text field on the system. The system MUST be able to display the information, after the searches described below are carried out, but text itself does not need to be in a searchable field. Note the reason may not be recorded on the referral as the allegation may refer to an open case.

The system MUST be able to search for allegations between



reasons. was to refer, the date the information was passed on.

The record also includes in the case of each allegation, the reason

why or

why not a referral was made.

The system supports a retrospective audit focusing on the number of allegations not referred to the police and the justifying reasons.

specified dates:

Search Input:

Date range for when allegation was made (e.g. 1 April to 31 March)

Search Return: List of allegations

The system SHOULD be able to search in the following ways for allegations between specified dates:

Search Input:

Date range for decision to refer to police (e.g. 1 April to 31 March)

Date range for decision not to refer to police (e.g. 1 April to 31 March)

Date range for information passed on to police (e.g. 1 April to 31 March)

Date range for adult name (e.g. 1 April to 31 March)

Date range for child name (e.g. 1 April to 31 March)

Search Return: List of allegations

The system SHOULD be able to provide a report (to support a retrospective audit )of sexual abuse allegations which WERE NOT reported to the police; the date the decision was made; and the justifying reasons.



The system SHOULD be able to provide a report (to support a retrospective audit )of sexual abuse allegations which WERE reported to the police; the date the decision was made; and the justifying reasons.

D42.1: Front-line staff and managers are able to access a chronology of key events in the life of each child for whom they have responsibility. This chronology is automatically updated when key events are recorded in the system, for example, when a child becomes looked after. Historic information is entered into the system as it is discovered through assessment and other case activity and subsequently output.

Front-line staff and managers are able to access a chronology of key events in the life of each child for whom they have responsibility.

This chronology is automatically updated when key events are recorded in the system, for example, when a child becomes looked after.

Historic information is entered into the system as it is discovered through assessment and

The system MUST support entry of historic information as key events, and also of key events that occur in the child’s life which would not otherwise be recorded in the normal course of children’s services assessment, planning, intervention or review.

The minimum attributes of the event that are on the chronology SHOULD be the date it occurred and text describing the key event.

It will become possible to bring together these 'key events' to form a chronology, in an appropriate and consistent format. This will display for each key event both the text describing the key event and the date it occurred (for example, address has changed and when the address changed). This is a SHOULD HAVE.

The system SHOULD HAVE the capability to print out the chronology



other case activity

and subsequently output.

D42.2: Specialised chronologies are outputted for different purposes i.e. health, education, change of carer histories, for use in court proceedings.

Specialised chronologies are outputted for different purposes i.e.

health,

education,

change of carer histories,

for use in court proceedings.

The system SHOULD be able to record groupings of the key events in a child’s life by topic, under the following headings: Social Services activity, Health, Education, Training and Employment, Changes to Legal Status, Placement History, Offences, and Events and Changes in birth family and social networks.

It will become possible to bring together the relevant 'key events' to form chronologies under each group heading. This will display for each key event both the text describing the key event and the date it occurred (for example, foster home has changed and when it changed). This is a SHOULD HAVE.

It SHOULD HAVE the ability to bring together the relevant 'key events' to form a chronology for use in court proceedings.

It should be possible to amend the fields recorded within the chronology for use in court proceedings (it is acceptable for this amendment to be achieved at a supplier or LA level). This SHOULD HAVE requirement is needed because DfES has yet to specify the fields required for the court chronology.



The system SHOULD be able to print out the chronology grouped by topic.

D43: Front-line staff and managers are alerted when key events (assessments, reviews etc) are approaching, due or overdue.

Front-line staff and managers are alerted when key events:

(assessments,

reviews etc)

are

approaching,

due

or overdue.

The system MUST be configurable to display on screen alerts to users to remind them of forthcoming key events (not restricted to within child’s record).

(NB: an “alert” can take the form of pop-up messages, dialogue boxes, colour coding, flags or verbal warnings on screen forms).

The events requiring alerts and the timescales are set by the review timescale, and are explained in the guidance. At a minimum the system MUST auto-generate alerts for the following, to support the nationally set timescales:

- Initial assessment (within 7 working days from the date of referral)

- Core assessment (within 35 working days of commencement)

- Child Protection Conference (within 15 working days of last strategy discussion)

- Date of Review Child Protection Conference

- Date of next review for LAC child

- Date of statutory visits for LAC children and visits for children on child protection register

It MUST be possible to set the timeframes that define ‘approaching’, ‘due’ and ‘overdue’, and where it is appropriate,



the frequency with which they are issued.

The system MUST force the alerts from pre-entered information.

Managers do not need routinely to receive their staff’s alerts, but MUST be able to interrogate the system to see what activities are approaching, due or overdue for their staff.

D44: The system records ‘flags’ that help to safeguard and promote the welfare of children, including adults who may constitute a threat to child or front-line worker, health conditions requiring special measures etc. These ‘flags’ give rise to alerts that are outputs (e.g. to the screen, printed output, e-mails etc) to allocated case workers etc and their managers.

The system records ‘flags that help to safeguard and promote the welfare of children, including:

adults who may constitute a threat to child or front-line worker,

health conditions requiring special measures etc.

These ‘flags’ give rise to alerts that are outputs (e.g. to the screen, printed output, e-mails etc)

This requirement is not necessarily for a “flag” but the system MUST HAVE the ability to display this information in a prominent position, within the child’s record. Free text is acceptable.

This information MUST be visible to the practitioner when they are in the child’s record.

The requirement that flags give rise to alerts that are outputs is NICE TO HAVE.



to allocated case workers etc and their managers.

D45: The system records electronically all new contacts and new referrals and checks these against existing cases as soon after receipt as possible and always within 24 hours.

The system records electronically all:

new contacts and

new referrals

and checks these against existing cases as soon after receipt as possible and always within 24 hours.

The system MUST automatically check any new children entered (contacts or referrals) against existing identities (based on child’s name, date of birth and address).

The practitioner has 24 hours to enter the information and for the system to return any matches with existing entries.

The system MUST indicate if the child is known. This means picking up potential matches to allow for misspellings and different addresses etc. so these can be checked by the user to see if it is the same child.

D46: The referral information so recorded is messaged to whoever is responsible for determining what action should be taken and thereafter transferred to staff working on the case.

The referral information so recorded is messaged to whoever is responsible for determining what action should be

The system SHOULD inform whoever is responsible for determining what action should be taken that action is required. This can be either through messaging the content of the referral information to this user, or by notifying them that action is necessary.

The system SHOULD also be able to inform staff working on a case that there are new tasks associated with the case, or in the instance of a new referral, that they now have case



taken

and thereafter transferred to staff working on the case.

responsibility. This can be either through messaging the content of the referral information to this user, or by notifying them that action is necessary.

The automation of the above processes is a SHOULD HAVE requirement.

The system MUST HAVE the capability for the user/LA to specify the person responsible for determining the action.

D47: Staff, other than the allocated front-line staff member, who receive information on a child can enter that information on to the case record for the child and alert the allocated worker.

Staff, other than the allocated front-line staff member, who receive information on a child can enter that information on to the case record for the child

and alert the allocated worker.

Any authorised worker MUST be able to enter information on a case and changes made MUST be logged as an audit record of who made what change and when.

The system SHOULD show the allocated worker the detail of any change and who input it. The system SHOULD automatically create an alert to the allocated worker by recognising that a change has been made by someone other than the allocated worker.

(NB the volume of alerts generated can be streamlined by ensuring that individual alerts are generated for changes to name, address, date of birth, but that other less fundamental changes can be flagged by a single “blanket” alert to indicate that 1 or more changes have been made).

The alert SHOULD be displayed on the allocated worker’s screen and not restricted to within the child’s record.

(NB: The case record in this instance is the child record).



D48: The system records the level of detail and summary information for all assessments (e.g. Initial and Core Assessment) that is set out in the relevant exemplars.

The system records the level of detail and summary information for all assessments

(e.g. Initial and

Core Assessment)

that is set out in the relevant exemplars.

The system MUST record the level of detail and summary information for all assessments. This requirement relates to the following exemplars:

Initial Assessment Record

CP1 Strategy – Record of Strategy Discussion

CP2 – Record of Outcome of s47 Enquiries

CP3 – Initial Child Protection Conference Report

Core Assessment Records (including maintenance of the separation of the different age bands).

Assessment and Progress Records (including maintenance of the separation of the different age bands)

Summary information is identified in these exemplars by a heading, “summary”.

D48.1: Data from referrals should automatically populate initial assessments.

NA Pre-population capability is SHOULD HAVE. It should be as shown in the eRecord demonstrator (i.e. the flow of information is in a forward direction only, and the pre-populated form can be edited).

Fields from the Referral and Information Record to pre-populate are: date of referral and child/young person’s details in the Initial Assessment Record.

The system SHOULD HAVE an audit trail capability to show how, when and by whom pre-populated information has been



amended.

NB: although it was not specified in LAC(2005)3, pre-population is central to the exemplars and process model for ICS, and there is a risk that not specifying this functionality will make the system difficult to use.

D48.2: Data from initial assessments should automatically populate core assessments/other records.

NB “other records” include: child plan; child protection exemplars

Pre-population capability is SHOULD HAVE. It should be as shown in the eRecord demonstrator (i.e. the flow of information is in a forward direction only, and the pre-populated form can be edited).

Fields from the Initial Assessment Record to pre-populate are child/young person’s details in the following: Core Assessment Records (all age bands); CP1 Strategy – Record of Strategy Discussion; CP2 – Record of Outcome of s47 enquiries; CP3 – Initial Child Protection Conference Report and Child or Young Person’s Plan.

In addition, information from the Initial Assessment Record about domains (Child’s Developmental Needs; Parenting Capacity; Family & Environmental Factors) and dimensions (e.g. health; education); summaries and analysis should also pre-populate Core Assessment Records.

The system SHOULD HAVE an audit trail capability to show how, when and by whom pre-populated information has been amended.




D48.3: Relevant data from core assessments should automatically populate the assessment and progress records.

NA Pre-population capability is SHOULD HAVE. It should be as shown in the eRecord demonstrator (i.e. the flow of information is in a forward direction only, and the pre-populated form can be edited).

Relevant information from the Core Assessments should pre-populate the Assessment and Progress Records. When creating a new Assessment and Progress Record, pre-population should be from the most recent Core Assessment.

Fields to be pre-populated in the Assessment and Progress Records are: child’s name, date of birth and responsible CSSR (local authority); comparable information about domains (Child’s Developmental Needs; Parenting Capacity; Family & Environmental Factors) and dimensions (e.g. health; education); any pertinent summary and analysis.


NB: although it was not specified in LAC(2005)3, pre-population is central to the exemplars and process model for ICS, and there is a risk that not specifying this functionality will



make the system difficult to use.

D49: The system records the level of detail and summary information for specific child protection activities (e.g. Strategy Discussions, s47 enquiry and Child Protection Conferences) that is set out in the relevant exemplars. The relevant information from the referral and information form and the initial and core assessment form should populate the child protection records.

The system records the level of detail and summary information for specific child protection activities

(e.g. Strategy Discussions,

s47 enquiry

and Child Protection Conferences)

that is set out in the relevant exemplars.

The information from the referral and information form and the initial and core assessment form should populate the child protection records.

Pre-population capability of the relevant exemplars is SHOULD HAVE. It should be as shown in the eRecord demonstrator (i.e. the flow of information is in a forward direction only, and the pre-populated form can be edited).

The fields to be pre-populated are:

- CP1 Strategy - Record of Strategy Discussion: child/young person’s details (from the Initial Assessment Record),

- CP2 – Record of outcome of s47 enquiries: child/young person’s details; actions; person/agency and date (from CP1Strategy – Record of Strategy Discussion); and initial plan from the Initial Assessment Record)

- CP3 – Initial Child Protection Conference Report: child/young person’s details (from the Initial Assessment and Core Assessment Records); key dates and actions section (the most recent information to be taken from: the Referral and Information Record; the Initial Assessment Record; the Core Assessment Records (all ages)); outline child protection plan info from CP2 – Record of Outcome of s47 enquiries.

In addition, information from the Initial and Core Assessments, whichever is the most recent, about domains (Child’s Developmental Needs; Parenting Capacity; Family & Environmental Factors) and dimensions (e.g. health; education); and analysis should pre-populate CP3 – Initial Child Protection



Conference Report.



There is no specific summary information field identified in these exemplars, but they are in effect summary forms, therefore all fields are to be captured.

D50: The system records the level of detail and summary information for planning and review that is set out in the relevant exemplars. The review exemplars should be pre-populated with the relevant fields (excluding actual outcome) from the Needs tables in the Plan exemplars.

The system records the level of detail and summary information for planning and review that is set out in the relevant exemplars.

Where there is a change to the type of Plan, any existing Plan should be “frozen” and the information should

Pre-population capability of the relevant exemplars is SHOULD HAVE. It should be as shown in the eRecord demonstrator (i.e. the flow of information is in a forward direction only, and the pre-populated form can be edited).

The review exemplars should be pre-populated with the relevant fields (excluding actual outcome) from the Needs tables in the Plan exemplars.


NB: although it was not specified in LAC(2005)3, pre-population is central to the exemplars and process model for



flow from the existing type to the next.

ICS, and there is a risk that not specifying this functionality will make the system difficult to use.

This requirement relates to the Needs tables in the following exemplars:

The Child or Young Person’s Child Protection Plan pre-populated from the Child/Young Person’s Plan and vice versa

Child or Young Person’s Care Plan pre-populated from the Child or Young Person’s Child Protection Plan and vice versa

Child or Young Person’s Care Plan pre-populated from the Child/Young Person’s Plan and vice versa

Child/Young Person’s Adoption Plan pre-populated from the Child or Young Person’s Care Plan and vice versa.

Child or Young Person in Need Review (pre-populated from Child or Young Person’s Plan)

Child or Young Person’ s Child Protection Review (pre-populated from Child or Young Person’s Child Protection Plan)

Child or Young Person’s Looked After Review (pre-populated from Child or Young Person’s Care Plan)

the Pathway Plan (pre-populated from the Child or Young Person’s Care Plan)

the Closure Record (pre-populated from whichever of Child or Young Person in Need Review, Child or Young Person’s Child Protection Review, Child or Young Person’s Looked After



Review and the Pathway Plan apply).

D51: Team managers are able to output basic statistics for the activity of their team (E.g. contacts, referrals, visits made, open cases, assessments (completed, in-hand), type of need, reviews (completed, in hand, due), court related activity, children identified as disabled.

Team managers are able to output basic statistics for the activity of their team, e.g.:

contacts,

referrals,

visits made,

open cases,

assessments (completed, in-hand),

type of need,

reviews (completed, in hand, due),

court related activity,

children identified as disabled.

The system SHOULD HAVE the capability for staff who are accountable at team level to output statistics about team activity.

Minimum statistics available from the system SHOULD be:

- Number of contacts within a reporting year. “Contacts” means contact with the service, but does not have to lead on to a referral. It may be handled by a contact centre.

- Number of referrals within a reporting year

- Number of cases currently open

- Number of initial and core assessments completed in a reporting year (including number of those within guidance timescales)

- Number of initial and core assessments currently in-hand (started but not completed)

- Number of children in receipt of service broken down by CiN codes

- Number of reviews completed (including number of those within guidance timescales) in a reporting year

- Number of reviews due within a user defined time period

- Counts for a reporting year of court related activity, including



interim care orders, care orders and criminal orders for young offenders.

- Number of children identified as having a disability

Most of these statistics are required for the returns required by DfES and described in detail in D39.

(NB: It is acceptable to produce this output via a reporting tool rather than from the ICS system).

The output SHOULD be to print and screen.

D52: Senior managers are able to output basic statistics of activity and outcome (performance indicator) data for all teams providing services for children in need and, in aggregation, for the children’s social care function of the children’s services authority.

Senior managers are able to output basic statistics of activity and outcome (performance indicator) data for all teams providing services for children in need

and, in aggregation, for the children’s social care function of the children’s services authority.

The information required here is as for D51 but is aggregated to a higher level – i.e. the information should be available for each team at team level and should be able to be aggregated to local authority level. As with D51, this is a SHOULD HAVE and the system SHOULD HAVE the capability for staff who are accountable for all teams to output statistics for all teams and to aggregate them.

(NB: It is acceptable to produce this output via a reporting tool rather than from the ICS system).

The output SHOULD be to print and screen.


integrated children’s system minimum compliance criteria

Documents