business requirements - cyfs integrated system · pdf fileprocess of upgrading to oracle r12....

1

BUSINESS REQUIREMENTS - CYFS INTEGRATED SYSTEM MANAGEMENT

1.0 BUSINESS REQUIREMENTS

Business requirements identify the strategic, tactical and operational needs along with the goals and/or objectives of the sponsoring organization.

# Requirements Priority

H - High M – Medium L – Low

Additional Information

B.1 The system should be a recognized (by Gartner or other 3rd Party Research), as a Human Services and / or Service/Case Management solution.

H

B.2 The system should be able to support integration with Government Financial Management Solution Accounts Payable, Accounts Receivable, Cash Management, Project Costing and General Ledger modules (Oracle eBusiness 11i).

H

Note: Government is currently in the process of upgrading to Oracle R12. The timeline for the R12 deployment is to be confirmed by the OCIO.

B.3 The system should be sufficiently “out of the box” to meet the business needs of CYFS. M

Sufficiently out of the box means that the solution should need limited customization to meet the needs of the Department.

B.4 The system should be flexible and scalable to meet the evolving needs of the Department, including changes to legislation, policies and organizational structure without incurring significant rework effort.

H

Standards – The solution should incorporate best of bread technology and architecture in alignment with the following standards

B.5 ISO 23801 – 1/2 H

B.6 ISO 19005 H

2




B.7 ISO 11179 H

B.8 CAN/CGSB 72.34-2005 H

2.0 REGULATORY REQUIREMENTS

Regulatory requirements address legislative or legal requirements of a business. They can be internal or external regulations. These are non-negotiable. The system should be able to support all regulatory and legislative requirements as identified below.




R.1 Child and Youth Advocate Act H http://www.assembly.nl.ca/legislation/sr/statutes/c12-01.htm

R.2 Child Care Services Act H http://www.assembly.nl.ca/legislation/sr/statutes/c11-1.htm

R.3 Children and Youth Care and Protection Act H http://www.assembly.nl.ca/legislation/sr/statutes/c12-2.htm

R.4 Young Persons Offences Act H http://www.assembly.nl.ca/legislation/sr/statutes/y01.htm

R.5 Adoption Act H http://www.assembly.nl.ca/legislation/sr/statutes/a02-1.htm

R.6 Youth Criminal Justice Act H http://laws.justice.gc.ca/eng/Y-1.5/20100401/page-

3




0.html?rp2=SEARCH&rp3=SI&rp4=all&rp5=youth%20criminal%20justice%20act&rp9=cs&rp10=L&rp13=50

R.7 Public Tender Act H http://www.assembly.nl.ca/legislation/sr/statutes/p45.htm

R.8 Access to Information and Protection of Privacy H http://assembly.nl.ca/Legislation/sr/statutes/a01-1.htm

R.9 Privacy and Procedure Manual H http://www.justice.gov.nl.ca/just/CIVIL/atipp/PrivacyPolicyandProceduresManual.pdf

R.10 Financial Administration Act H http://assembly.nl.ca/Legislation/sr/statutes/f08.htm

R.11 Management of Information Act H http://assembly.nl.ca/Legislation/sr/statutes/m01-01.htm

R.12 Evidence Act H http://assembly.nl.ca/Legislation/sr/statutes/e16.htm

R.13 Electronic Commerce Act H http://assembly.nl.ca/Legislation/sr/statutes/e05-2.htm

R.14 Recording of Evidence Act H http://assembly.nl.ca/Legislation/sr/statutes/r07.htm

2.1 Departmental Standards and Polices

The Department of Child Youth and Family Services (CYFS) Standards and Policy requirements address standards and guidelines for service delivery. The information system must support the administration and monitoring of service delivery in relation to the standards and guidelines.

4




SP.1 Adoptions Standards and Policy Manual H

SP.2 Child Care Centres Regulations Policies and Standards H http://www.gov.nl.ca/cyfs/publications/childcare/childcare_centres_policies.pdf

SP.3 Child Care Services Subsidy Manual H http://www.gov.nl.ca/cyfs/publications/childcare/february2005.pdf

SP.4 Child Youth and Family Services Standards and Policy Manual H http://www.gov.nl.ca/cyfs/publications/child

_youth_family_services_manual.pdf

SP.5 Community Youth Corrections Standards and Policy Manual H

SP.6 Extrajudicial Sanctions Standards and Practices Manual H

5

3.0 FUNCTIONAL REQUIREMENTS

Functional Requirements have been documented based on a common Service Framework which provides a common high level process, look and feel across the various CYFS Programs and Services in scope for the CYFS ISM project.

A set of key concepts was defined for the purpose of clarity and specificity across all the program areas within the context of defining the capabilities of a new system. Some of the concepts may be referred to by different terms within the program policy and practice but for the purpose of defining the new system the terminology outlined in this section is used. Figure 1 below depicts the key ISM concepts and their relationships to each other, followed by descriptions of each of the concepts.

Family

…Service

Individual GroupIs related

to

Is a member

of

Service

Service Recipient(s)

Service Provider(s)

Receives ProvidesManagesApproves

Other Participants(s)

Is Involved in

Resides at

Service Package

Activities DocumentsPart Of Part Of

Location

Operates at

Figure 1 Key ISM Concepts & Relationships

6

Service A line of business defined to address a type of need (which aligns with the chart of accounts), such as Protective Intervention, Residential Youth Services, Child Welfare Allowance, Caregivers Service, Extra Judicial Sanctions, Inter-provincial Adoptions, Child Care Subsidy, Child Care Licensing.

Service Package A set of services provided to the same service recipient(s), and managed in an integrated manner. The services may be provided by different workers and be part of different programs.

Participants The various people/entities participating in a service in some way. In relation to a service, participants may have one of the following four roles:

• Service Recipients – the individual or grouping of individuals who is receiving a service from the Department of Child Youth and Family Services (CYFS).

• External Service Providers – the external person or group who, through contract or agreement, provides services to service recipients of the Department of Child Youth and Family Services. The service may be monitored and tracked by the Department.

• Internal Service Providers – CYFS staff

• Other Participants – any other individual involved in the service or with the service recipient in some way but does not receive direct services other than funding from the Department.

See Section 18 for examples of classifications of external groups involved with service recipients.

Family A collection of identified, immediate related (by blood, law or other recognized means) individuals.

Group Permanent Group: A group/organization that exists as an entity for an extended period of time such as those that are licensed or approved by CYFS; legal organization entities; and community committees. Temporary Group: A collection of identified or unidentified service recipients brought together for a short period of time to receive a service such as training.

Location

A permanent or temporary place of residence such as the home of mother, father, relative, foster homes, group homes, custodial centres, or hospitals.

7

Activity

An action performed as part of delivering the service (e.g client contact, a meeting, site visit, creating a document or report, attending a court hearing, providing training, consulting, etc.)

Documents

The documentation related to the service. Any external or internal document whose completion or contents needs to be tracked and/or accessible. (e.g. applications, assessments, plans, agreements, court orders, reports & summaries, etc.)

A Service may have one or more Service Recipients and is provided by one or more Service Providers (mostly CYFS staff) and generally progresses through a series of common stages.

8

• Receive & Respond to an Inquiry• Receive a Request for Service (External or Internal)• Receive an Allegation

Request

• Preliminary quick assessment to determine potential service eligibility and / or response priorityScreen

• Perform full assessment Assess

• Develop the plan(s) for providing the servicePlan

• Provide and Monitor the service(s)Service & Monitor

• Review the progression and effectiveness of the service• Determine whether to reassess, re-plan, continue or close Review

• Service(s) complete• Close the fileClose

Request or Allegation appears valid and within CYFS service mandate

Request or Allegation passed initial screening

Assessment identified the required service(s)

Service Plan completed

Review required (periodic or situational)

Service objectives met and/or service no longer required

6

Figure 2 Service Framework

Some stages, particularly Screen, are not applicable to all services. Although the general scope and purpose of each stage are common across all services, the particular set of activities relevant to each stage will be different depending on the type of service. This common framework enables consistent reporting and analysis of the progress of services while allowing flexibility of workflow within each stage. Using the framework for tracking service progress also enables identification of potential areas for process and standards improvement or policy adjustment.

9

Request

The Request stage is the entry point for capturing either the initiation of a service or for quickly capturing information related to inquiries and complaints which do not result in services or may not result in a service until a later date.

Screen

The Screen stage is applicable to services which have a two part assessment, the first part being an initial short process to either screen out ineligible service recipients prior to doing a full assessment or to determine response priority.

Assess

The Assess stage includes a full assessment of the service recipient’s situation, needs and/or eligibility for the service and the identification of the appropriate type of service(s) required to meet those needs. The complexity and duration of this stage will vary greatly depending on the type of service.

Plan

The Plan stage builds on the assessment and involves developing a service plan and potentially agreements with the service recipient.

Service & Monitor

The Service & Monitor stage covers the delivery of the service components identified in the plan, routine monitoring and review of the service progress

Review

The Review stage is for periodic review activities that are different to and distinct from the on-going monitoring activities

Close

The Close stage is the final stage of ending the service. The close stage is fairly consistent across all the services and involves logging the date that service delivery to the service recipient ended, logging the closure reason, completing any outstanding activity notes, etc. and finally closing the service in the system. In some services there is also a closure summary and supervisor approval to close the service.

3.1 Functional Area 1 – Service Recipient, External Service Provider and Participants Management

Description: The solution must provide a 360 degree view of the service recipient and participant including all of the interactions the service recipient or participant has across CYFS programs and services. An individual or group can be a service recipient. The solution should support creation, update, review, merge and deletion of service recipient and participant profiles, provide business rules to eliminate duplication of records, allow for efficient search methods and enable appropriate up-to-date access of service recipient and participant information by authorized service providers.

10




3.1.1 The system should have the ability to create a profile for an individual and group and assign a unique identifier for the profile.

H

3.1.2 The system should have the ability to indicate the level of identity assurance applied to a profile. H

3.1.3 The system should have the ability to recognize when a duplicate profile is potentially being created and alert the user.

H

3.1.4 The system should have the ability for an authorized non-technical user to merge profiles which are deemed to be duplicated.

H

3.1.5 The system should have the ability to manage different types of profiles (e.g., individuals, group homes, community agency).

H

3.1.6 The system should have the ability to support capturing a wide range of Individual Profile information such as:

• First and Last Name • Middle Name(s) • Aliases & Type (including maiden name, previous

married name) • Birth Date • Death Date • Marital Status • Gender • SIN • MCP Number • Ethnicity • Location Information • Mailing Address • UPI/Client Registry Address

H Physical characteristics are particularly needed to track children in care who go missing

11




• Physical Characteristics • Place of work • Profession • Contact Information (phone, email, type/role etc.)

Could be multiple contacts • Current school and grade (for children in care) • Child Care Certification & Experience

3.1.7 The system should the ability to track the history of an individual’s name changes, e.g. maiden name, previous married name

H

3.1.8 The system should have the ability to track the history of address changes for groups and individuals, H

3.1.9 The system should have the ability to indicate on a search or family relationship tree if the person is deceased. M

3.1.10 The system should have the ability to support capturing a wide range of Group Profile information such as:

• Group Type • Legal Name • Common Name • Location Information • Mailing Address • Business Registration Number • Status (active, on-hold, etc) • Key Contact/Member Information (Role Type,

Name, phone, email, etc.) • Board / Program Chair & Contact Info • Board / Program Treasurer & Contact Info • Licensee & Contact Info • Corporate Information • Various attributes depending on group type (e.g.,

H

12




residency type, preferences{e.g. gender, age},) • Comment

3.1.11

The system should have the ability to link CYFS satellite office locations to hub locations.

H For example Family Resource Programs often have a hub office site with multiple satellite locations. Only location information is needed about satellites.

3.1.12 The system should have the ability to search for profiles based on active service information and display key service information with the profile in the results list.

H For example when searching for active foster families in a particular service area the vacancy number should also be displayed as part of the search results.

3.1.13 The system should have the ability for a user to search for a Profile by name including aliases, address, phone number or group type.

H

3.1.14 The system should provide the ability for a user to search for profiles based on any other profile related fields (e.g., SIN, MCP number, business registration number).

M

3.1.15 The system should have the ability for a user to perform a single search for a Profile that may be either an individual or a contact/member of a group

H For example, Foster Parents who may be represented as individuals and as part of a group

3.1.16 The system should have the ability to track and manage the relationships that exist between profiles. H

3.1.17 The system should have the ability to manage family relationships including the ability to separate or link individual profiles when a family composition has changed.

H The concept of a family is a collection of individual profiles which are linked in some type of relationship.

3.1.18 The system should have the ability to assign profiles different statuses such as Active, Inactive, On-Hold, etc. L

13




3.1.19 The system should have the ability to identify and enforce mandatory input fields. H

3.1.20

The system should have the ability to prevent profiles from being saved that do not contain the minimum amount of information.

M Minimum amount will vary depending on the type of profile. Mandatory fields will be limited to critical identifying information only and will be kept to the lowest minimum fields required to identify a profile.

3.1.21 The system should provide the ability for a user to search for profiles based on phonetic search (similar sounding) technology for first or last names or group names.

M

3.1.22 The system should have the ability to maintain a history of a profile and its relationships with other profiles. H

3.1.23 The system should have the ability to track all interactions the profile has or has had with CYFS services. H

3.1.24 The system should have the ability to distinguish and filter service recipient interactions from participant interactions when displaying all CYFS service interactions for the profile.

H

3.1.25 The system should provide the ability to access profile information across programs and services where appropriate and restrict visibility to related services where required.

H Generally want open visibility to profiles except in certain cases, e.g. in the case of VIP restriction, Adoptions vaulting.

3.1.26 The system should have the ability to attach electronic documents in multiple formats (MS Word, PDF, Excel, RTF, JPEG, BMP, etc) to a profile.

H

3.1.27 The system should have the ability to attach an individual’s photo to their profile. H

14




3.1.28 The system should have the ability to print a summary of the profile including but not limited to:

• Name • Date of Birth • Photo • Physical characteristics • Alerts

H This requirement is especially pertinent for communicating information about missing children or generating a profile of the child for a foster family. The profile summary may vary by service type.

3.1.29 The system should have the ability to attach photos and comments on foster family profile so a social worker can share this with a child prior to placement.

L

3.1.30

The system should have the ability to manage alerts on a profile including:

• Start & End Dates • Alert Type • Alert Description

H Manage means to create, review, update and delete as appropriate using effective dates.

An alert is safety related information about the individual (e.g., tendency for violence, conviction of crimes against children) or other key information related to interacting with the individual (e.g. bad times to call).

3.1.31 The system should provide the ability to manage critical service recipient information at the profile level. This could include but is not limited to:

• Allergies • Medial Issues / Medication Required • Etc.

H

3.1.32 The system should prevent more than one user from updating the exact same profile information at the same time.

H

3.1.33 The system should provide the ability to support maintaining location information for each profile, which may include H

15




multiple active locations, location characteristics and provide a history of past locations and their effective dates.

3.1.34 The system should have the ability to create and manage location profile information. Including:

• Address • Direction to the location • Geographical Coordinates • Type

H Type is particularly used if the location is not linked to a group (e.g., hospital)

Original requirement is now split into two requirements

3.1.34a The system should have the ability to map geographic coordinates to a location. L

3.1.35 The system should have the ability to link locations to different types of geographical area groupings including:

• Community Accounts (i.e. neighborhood groupings) • Electoral District

M

Original requirement is now split into two requirements

3.1.35a The system should have the ability to link locations to Community Account groupings L

3.1.36 The system should have the ability to link locations to organizational groupings such as CYFS Region, Zone and District. H

3.1.37 The system should have the ability to manage the relationship between individuals, groups and locations including:

• Start date • End date • Occurrence (weekend, every second weekend)

H

16




3.1.38 The system should have the ability to future date changes and edit profile information (e.g., temporary phone number). M

3.1.39 The system should have the ability to capture information about out of province treatment centres/placements which do not go through the same approval and monitoring processes as those which are in province.

H

3.2 Functional Area 2 – Service Management

Description: The system must provide the ability to define and manage a variety of service type definitions which are composed of activity lists, key information and business rules based on program policy. The system must provide the ability to initiate a service for a service recipient(s). Services are provided in a common service framework which includes request, screen, assess, plan, service and monitor, review, and close stages. The solution must have the ability to provide a 360 degree view of the service including, who is involved in the service and the detailed service history. The solution should also provide functionality to track the service progression and all involved participants across the service stages.




3.2.1 The system should have the ability to provide pre-defined activity lists associated with various service types and stages.

H An activity list is a list of documents to be received or completed and key activities to be completed for a particular service stage for a specific service type.

3.2.2 The system should have the ability for a configuration administrator to create and manage activity lists. H

3.2.3 The system should have the ability to allow the user to define recurring items in the activity list per individual service instance.

H Reoccurring items include documents which require review or revision at set intervals (e.g., risk assessments have to be reviewed every six months).

17




3.2.4 The system should have the ability to create a service for a service recipient(s) and assign a unique service identifier. H

3.2.5 The system should have the ability to allow an authourized person to move service information added on an incorrect client or in an incorrect service

H

3.2.6 The system should have the ability to back date the start of a service for specific service types. H The original requirement is now split into

two requirements

3.2.6a The system should have the ability to future date the start of a service for a specific service type. M For example if a service provider knows

there is training next month they could create a service for the training now.

3.2.7 The system should have the ability to identify if the same active service type already exists for the same service recipient prior to creating a duplicate and the ability to prevent where applicable.

H

3.2.8 The system should have the ability to merge duplicate services of the same service type. H

3.2.9 The system should have the ability to re-open a closed service for a service recipient where applicable. H

3.2.10 The system should have the ability to present a consolidated view of all services and related documentation for the same service type for the same service recipient.

H

3.2.11 The system should have the ability to allow services to be packaged together for integrated management. H

3.2.12 The system should have the ability to assign services different sub types H For example type of adoption application or

protective intervention intake.

18




3.2.13 The system should have the ability to change the service sub-type during the duration of the services. H For example a Youth Service may change

from residential to non-residential.

3.2.14 The system should have the ability to assign services different statuses such as In Progress, Closed, On Hold, etc. H

3.2.15 The system should have the ability to link multiple service recipients to a service and multiple services to a service recipient.

H

3.2.16 The system should have the ability to manage a single financial assistance service with a single assessment for an entire family but multiple payments to the same or different vendors for each of the children involved.

H

3.2.17 The system should provide the ability for users to search for service recipients’ services based on any service related field parameter.

H For example a non technical business user should be able to search for all services which have a high risk rating.

3.2.18 The system should have the ability to provide a summary of the service based on detailed information stored in the system. The summary may include but is not limited to:

• Identification of participants involved in the service • Risk Rating (if applicable) • Flags and Notifications about potential issues and

risks related to the service (including information on related service entities such as location)

• Status on the documentation for the service

H Users should not have to search through multiple detail screens to understand summary information or the “big picture”.

3.2.19 The system should have the ability to track the history of and manage the relationships that exist between services and service providers.

H

3.2.20 The system should have the ability to track repeat service H

19




recipient involvement with CYFS services.

3.2.21 The system should have the ability to prevent services from being saved that do not have at least one service recipient attached to the service except for specified services (such as Child Care Capacity & FRP).

H

3.2.22 The system should have the ability to prevent services from being saved that do not have at least one service provider attached to the service.

H

3.2.23 The system should have the ability to assign ownership of a service to a CYFS service provider. H

3.2.24 The system should have the ability to transfer services or service packages from one service provider to another service provider either individually or as a group or partial group.

H For example transferring all of one service provider’s services to another service provider.

3.2.25 The system should have the ability to split the transfer of services or services packages between multiple internal service providers choosing which services go to which service provider.

H For example from one service provider to five service providers.

3.2.26 The system should have the ability to support service action priorities (e.g. immediate, non-immediate, etc). L

3.2.27 The system should prevent more than one user from updating the exact same service information for a service recipient at the same time.

H

3.2.28 The system should have the ability to provide various user defined summaries of service related information. H

3.2.29 The system should have the ability to view a service recipient’s service information based on a historical "point in H

20




time".

3.2.30 The system should have the ability to pre-populate relevant information in a new service that is related to an existing service

H The purpose of this requirement is to reduce duplicate data entry.

3.2.31 The system should have the ability to support service recipients being involved in more than one service (e.g. receiving benefits/services from more than one program area simultaneously).

H

3.2.32 The system should have the ability to identify the location of the hardcopy documents associated with each service. M

3.2.33 The system should have the ability to generate and manage waitlists for a specific service. H For example CYFS has waitlists for

referrals to internal resources such as Behaviour Management Specialists, Adolescent Mental Health Counsellors and Family Service Counsellors in some regions

3.2.34 The system should have the ability to associate activity notes with a service. H Activity notes should comprise both free

text and drop down/checklist boxes to help standardize and improve the efficiency of completing activity notes and reporting on activity type.

Activity notes should not have a character limit.

3.2.35 The system should have the ability to duplicate and edit an entire activity note across multiple services. H

3.2.36 The system should provide the ability to enable users to sort activity notes by date of occurrence, date entered, activity H

21




note type, etc.

3.2.37 The system should have the ability to attach emails to the service. H

3.2.38 The system should have the ability to spell check (include capability to add words to dictionary) and grammar check activity notes and indicate to the user when a mistake has been made.

H CYFS users would like the system to have active spell checking where misspelled words are underlined or highlighted

3.2.39 The system should have the ability to view and print a consolidated view of activity notes for a particular service recipient across all of their services and filter by an activity note type or note author.

H

3.2.40 The system should have the ability to configure mandatory and optional data fields for each service type. H

3.2.41 The system should have the ability to highlight mandatory fields to the user. H

3.2.42 The system should have the ability to flag certain fields in the service as mandatory once a particular document or activity is complete.

M For example when the Risk Assessment document is complete the Risk Rating must be entered in the system.

3.2.43 The system should have the ability to capture all information relevant to Child Care Services Licenses including but not limited to:

• License Number • Licensee / Owner • Operator Information (Name, Contact Info,

Certification Level, Years of Experience, Not applicable for Homes)

• License Start Date • License Expiry Date

H

22




• License Status (In Process, Operational, Conditional, Varied, Suspend (Suspend End Date, Closed)

• Number of Homerooms - For each home room - Age Range, Capacity, Hours of Operation

• Number of full time spaces • Number of part time spaces • Incorporation date and number, effective and expiry

dates • Hours, days, weeks of operation

3.2.44 The system should have the ability to track additional information on Child Care Service (CCS) operators such as expiry dates of certification and first aid.

H

3.2.45 The system should have the ability to track and report on Warnings linked to a Child Care Services Licensing service. H Warnings should comprise both free text

and drop down/ checklist boxes to help standardize, improve the efficiency of logging warnings and reporting on warning type.

3.2.46 The system should have the ability to send a notification to the service provider and/or manager when the number of Warnings or Quality of Care, group home incidents, etc. reaches a certain threshold within a specified time period.

L Rating lowered as this level of monitoring would be expected to be completed as part of ongoing service delivery. The system should not be expected to guide practice.

3.2.47 The system should have the ability for the user to select warnings on a Child Care Licensing service and link them to a Child Care Licensing Investigation service.

L

3.2.48 The system should have the ability to track and report on Quality of Care or Group Home incidents linked to a Caregivers or Group Home service.

H Quality of Care incidents should comprise both free text and drop down/checklist boxes to help standardize, improve the efficiency of logging quality of care incidents and reporting on quality of care incident type.

23




3.2.49 The system should have the ability to track and report on Conditions linked to a Licensing or group approval service including but not limited to:

Condition Type Condition Description Target Compliance Date

H Licensing conditions should comprise both free text and drop down/checklist boxes to help standardize, improve the efficiency of logging conditions and reporting on condition type.

3.2.50 The system should have the ability to store and retrieve various document templates related to specific services and service stages (for example, a risk assessment template, Safety Plan Template).

H Documents should be available to the system user from multiple paths within the system.

3.2.51 The system should have the ability to attach and access electronic documents to a service including but not limited to:

• Risk Assessments • Service Plans • Photographs • Summary Reports • Letters and Correspondence to the Service

Recipients involved with the service

H The system will not be the department’s document management system but access to viewing and attaching documents will be available in the system. Staff should not have to sign into another system to view documents.

3.2.52 The system should have the ability to attach electronic documents in multiple formats to an activity list item. H

3.2.53 The system should have the ability to open a document template directly from an activity list item. M

3.2.54 The system should have the ability to directly open a document that is linked to an activity list item. M

3.2.55 The system should provide the ability to track requests to CYFS including the type of request, the origination of request and if action is required.

H Requests are initial points of contacts between CYFS and Participants that may or may not lead to an active service.

24




3.2.56 The system should have the ability to initiate a service from a request pre populating any applicable fields. H

3.2.57 The system should have the ability to indicate what service stage (request, screen, assess, etc) a service recipient is in for a specific service.

H

3.2.58 The system should have the ability to determine how long a service is in a particular service stage. H

3.2.59 The system should have the ability to track the request date, receipt date, system date, and signed date of documentation required from Service Recipients in each service stage. These could include but are not limited to:

• Birth Certificates • Marriage Forms • Physician’s Report • Certificates of Conduct • Application Forms • Openness Agreement • Child Medical History • MCP Application • Business Plans

H Please refer to the CYFS To-Be Service Framework and High Level Process Approach document for additional details on the required information tracking requirements for each service type.

3.2.60 The system should have the ability to track the start date, completion date, system date, responsible worker and other key information for various documentation activities completed by workers for service recipients including but not limited to

• Risk Assessment • Safety Assessment • Safety Plan • Pre Sentence Report


25




• Investigation Report • Out of Province CYFS checks • Plans of care • Home/Center Assessment • Case Plan • Reassessment/Review

3.2.61 The system should have the ability to track completion of various key activities including but not limited to:

• PRIDE Training • Review • Approval


3.2.62 The system should have the ability to track who was the approver for approval activities H

3.2.63 The system should have the ability to track the length of time between activities in a service. M

3.2.64 The system should provide the ability to implement a tool which supports qualitative (text based) and quantitative (scaled questions) information and generates a rating.

L The tool should provide both free text and drop down lists to enable standardization of the information stored in the tool.

3.2.65 The system should have the ability to create, update, search, view and print information stored in the rating tool.

L Protective Intervention and Youth Corrections use risk assessment rating tools.

3.2.66 The system should have the ability to support updating/amending a rating tool over time and not force the user to re-enter data that has not changed.

L

3.2.67 The system should maintain a history of point-in-time ratings with the ability to automatically compare them to see changes over time.

L

26




3.2.68 The system should have the ability to print a blank electronic rating tool to be completed by hand. L

3.2.69 The system should have the ability to populate fields with data using pre-set criteria from application information, benefit tables or other databases. L

3.2.70 The system should have the ability to identify cross program and benefits dependencies (e.g., cannot receive certain benefits simultaneously) and notify the service provider. L

3.2.71 The system should have the ability to accept input of data records electronically or by manual data entry from documents containing information for multiple service recipients and associate the data records with individual services.

H

3.2.72 The system should have the ability to identify (either manually or automatically) specific service recipient events (e.g., dependent turns 16), trigger a notification to the appropriate service provider, and potentially close the existing service and start a new one.

L E.g., close an In Care service and start a Youth Services service

This information should be available through reporting rather than notifications

3.2.73 The system should have the ability to track external referrals out (e.g., referral to addictions counseling). Tracking could include referral status and progress.

M

3.2.74 The system should have the ability to identify and track various service related items such as:

• Goals and Progress • Conditions and Compliance

H

3.2.75 The system should have the ability to notify an approver when a document is ready for review and approval. H

27




3.2.76 The system should have the ability to monitor for overdue activities and send notifications to the appropriate service providers/supervisors and/or produce regular monitoring reports.

H

3.2.77 The system should have the ability to configure a rules engine to assist in monitoring policies and standards. H

3.2.78 The system should have the ability to 'freeze' and retain all documentation that may be subject to investigation/discovery or as required.

L

3.2.79 The system should have the ability to link new request or incoming referrals to an existing service.. H For example additional allegations are

made for an active protective service

The system should have the ability to capture incoming referral information including but not limited to:

• Referral date • Date received • Referral source information (name, agency, role,

kept confidential indicator) • Screening indicator • Response priority • Responsible service provider

H

3.2.80 The system should have the ability to link new allegations to an existing incoming referral. H

3.2.81 The system should have the ability to alert to repeat occurrences of the alleged offender name across allegations/referrals.

M

3.2.82 The system should have the ability to notify if the number of specified groupings of allegations types has reached a certain threshold for a particular service or service recipient

L This is part of ongoing service delivery and should be practice driven as opposed to system driven.

28




3.2.83 The system should have the ability to capture the following as part of a referral out:

• Why the referral was made • Referral to whom • Date of referral • Any subsequent contact made with the referred

person/agency

M

3.2.84 The system should have the ability to initiate internal referrals / requests for service and auto create and pre-populate the appropriate request / service.

H

3.2.85 The system should have the ability to track information on parental access to a child in continuous custody where the PIP service has been closed.

H

3.2.86 The system should have the ability to access activity notes on supervised access via both the parent(s) and the child(ren)’s profile.

H

3.2.87 The system should have the ability to quickly flag if a child’s placement is out of province H

3.2.88 The system should have the ability to capture the reason for a child being moved out of one placement and into another, and link it both to the child and the placement the child left.

H

3.2.89 The system should have the ability to track the start and end dates of placements, accessible via the child and the caregiver / home / centre.

H

3.2.90 The system should have the ability to track if siblings are placed together or apart. H It is expected this would be completed

through location and not require separate functionality.

29




3.2.91 The system should have the ability to track which relatives have been contacted for potential placement of the child and the reason the child was not placed with the relative (i.e. relative declined or reason relative deemed not suitable).

H

3.2.92 The system should have the ability to track repetitions of a stage in a service (e.g., protective intervention assessment). H For example: There is an active protective

intervention service in place and a new type of allegation is received. The assessment stage for that service will need to be repeated for the new allegation.

3.2.93 The system should have the ability to capture sentence hearing information details including but not limited to:

• Hearing Date • Hearing Location (drop down list) • Assessments Ordered (check boxes)

H

3.2.94 The system should have the ability to capture offence details including:

• Offence Date • Legal statute • Offence section under the legal statute (imported

with ability to overwrite) • Offence Description from the legal statutes (imported

with the ability to overwrite) • Hybrid Summary or Indictable offence

H

3.2.95 The system should have the ability to capture sentence details including but not limited to:

• Sentence Start date • Sentence Duration • Sentence Type (drop down with Other and enterable

H

30




description) • Number of Hours • Fine amount • Consecutive / Concurrent

3.2.96 The system should provide a robust calculation tool incorporating sentencing rules to determine the sentence start and end dates.

H Subsequent sentencing or incidents can impact the start date of existing consecutive sentences

3.2.97 The system should provide the ability for an approved user to override the calculated sentence end date. H

3.2.98 The system should be able to link and manage the relationship between sentences and offences including:

• One sentence to multiple offences • Multiple sentences to one offence

H

3.2.99 The system should have the ability to link sentences to active correctional statuses. H Correctional statuses could include:

• Open custody • Non-custody • Secure Custody • Supervision

3.2.100 The system should have the ability to track information on one or more Probation or Supervision Conditions linked to a sentence and ordered by the court.

M Initially these orders may be scanned and stored in the system.

3.2.101 The system should have the ability to track information on additional Conditions specified by the Director. H Conditions should comprise both free text

and drop down/checklist boxes.

3.2.102 The system should have the ability to track information on one or more Incidents linked to a Community Youth H Synergies between all programs’ incidents

and other adverse events should be identified and common functionality

31




Corrections service including but not limited to:

• Incident Type • Incident Date • Actions taken • # of days AWOL

designed.

3.2.103 The system should have the ability to recalculate the sentence end date and affected subsequent sentence start dates based on the # of days AWOL.

H

3.2.104 The system should have the ability to track information on Reintegration Leave Approval including but not limited to:

• Leave Type (Overnight, Day Pass, etc.) • Reason • Dates and time of leave • Revocation • Revocation Reason • Condition descriptions (select from standard list plus

ability to add additional condition free form text)

H

3.2.105 The system should have the ability to generate a reintegration leave approval form from the information entered in the system to be printed and signed.

H

3.2.106 The system should have the ability to track and report on mandatory visits with the service recipient including but not limited to:

• Date • Contact Type • Intervention Type • Client attendance

H

3.2.107 The system should have the ability to track one or more service recipient agreement/plan components including but H

32




not limited to

• Type • Description • Target Completion Date • Date Completed

3.2.108 The system should have the ability to track information on sentence appeals and be able to recalculate sentence end date and affected subsequent sentence start dates (where applicable) based on the appeal outcome Including but not limited to:

• Hearing date • Appeal type • Outcome • Affected Sentences

H

3.2.108 The system should have the ability to track information on Sentence Reviews and be able to recalculate sentence end date and affected subsequent sentence start dates (where applicable) based on the review outcome including but not limited to:

• Initiator type • Outcome • Affected Sentences

H

3.2.109 The system should have the ability to track information on Mandatory Reviews and be able to recalculate sentence end date and affected subsequent sentence start dates (where applicable) based on the review outcome including but not limited to:

• Date Submitted to Court • Outcome • Affected Sentences

H

33




3.2.110 The system should have the ability to track the non disclosure date and impose access restrictions after this date. H

3.2.111 The system should have ability to calculate the non-disclosure date for youth corrections service information. H

3.2.112 The system should have ability to track breach or suspected breach of supervision information and be able to recalculate sentence end date and affected subsequent sentence start dates (where applicable).

H

3.2.113 The system should have the ability to match service recipients with the appropriate placement.

M

For example children needing to be placed in Foster Care should be able to be matched to a Foster Family based on criteria including age, gender and special needs.

3.2.114 The system should have the ability to track protective intervention court information including but not limited to:

• Hearing Dates • Court Order Start and Expiry Dates, • Outcome

H Synergies between court information for corrections and child protection/in care should be identified and common functionality designed.

3.2.115 The system should have the ability to select services for audit using configurable risk-assessment criteria and sampling techniques (e.g. random or targeted).

M

3.2.116 The system should have the ability to format a checklist of items to be verified or audited and record results of audited items.

M

3.2.117 The system should have the ability to produce a log identifying open audits and investigations based on business rules.

M

34




3.2.118 The system should have the ability to flag services and distinguish where audits and investigations are complete. H

3.2.119 The system should have the ability to record and report results of audits or investigations. L

3.2.120 The system should have the ability to support the tracking of:

• Adverse Event Investigations Reports • Ministerial Inquiries regarding a service recipient

and/or service Including the date the request was made, who made the request, what service the request is regarding and the type of adverse event or inquiry

H Adverse events may include the death of a child.

3.2.121 The system should have the ability to track both the date the provision of service to the service recipient is ended and the date the service is closed in the system, as well as the closure reason.

H There is often a gap between the actual date the service is no longer being provided to the service recipient, and the date all the information in the system is completed and the service is closed from a system perspective.

3.2.122 The system should have the ability for the user to select the number of copies and pages to print of a document, report or letter.

M

3.2.123 The system should have the ability to generate hard copy printouts of user selected key service information.

H

3.3 Functional Area 3 – Service Provider Management

Description: The system must provide the ability to manage and support Internal (CYFS Staff) and External (Contracted) service providers. The system must be able to link service providers across multiple services and assist in the assignment of services to service providers to give a full view of the CYFS work effort. The system must provide tools such as Keep in Views, Notifications, Alerts and “My Caseload” views to support the

35

activities of internal service providers. The system must also be able to effectively manage service agreements and contracts between CYFS and external service providers.




3.3.1 The system should provide the ability to allow administrators to setup service provider profiles including but not limited to:

• Type (internal/external) • Position • First Name • Last Name • Site • District • Zone • Region • Telephone Number • Direct Supervisor/Manager • Start/End Dates

H

3.3.2 The system should have the ability to maintain a history of changes to service provider profile information. H

3.3.3 The system should have the ability to assign a unique service provider ID for both internal and external service providers. H

3.3.4 The system should have the ability to indicate if a service provider has had a CYFS records check completed, the date it was completed and the next review date. H

3.3.5 The system should have the ability to temporarily assign a higher classification to a service provider based on CYFS policy and process. H

If a Social Worker is covering a supervisor’s leave, or a supervisor covering for a zone manager.

3.3.6 The system should have the ability to define a hierarchy of responsibilities, approvals and enable delegated approval H

36




authority.

3.3.7 The system should have the ability to define a temporary new responsibility, etc for the purpose of covering for a supervisor / manager / director H

3.3.8 The system should have the ability to provide a method for assignment of a service to a service provider one at a time or by batch. H

3.3.9 The system should provide the ability to link multiple service providers to a service (e.g., multiple Social Workers linked to a service, Program Consultant and a Capacity Consultant linked to a service).

H

3.3.10 The system should have the ability to provide ‘my caseload view’ to support the management of social worker activities. This view could include:

• My Services • My Service Recipients with phone numbers • Recent Services • Recent Service Recipients • Upcoming activities / KIVs • Overdue activities • Number of active services

H

3.3.11 The system should have the ability to allow non-technical business users to customize the types of information shown on their “my case load view”. M

3.3.11.1 The system should have the ability to allow supervisors/ managers to see the “my caseload view” of their subordinates. H

3.3.12 The system should have the ability to maintain a history of changes in service provider assignment for individual services. H

37




3.3.13 The system should have the ability to provide a summary profile for external service providers including:

• Name of provider • Location of provider • Contact information • Type of service provided

L

3.3.14 System users should have the ability to search for external service providers based on a variety of fields including:

• Type of service provided • Location • Name of external service provider • Business Number (if applicable) • Phone Number

M

3.3.15 The system should have the ability to support the development of a Services Agreement (a contract between the external service provider and CYFS) including:

• Service Provider • Reason for Involvement • Service Provider Activities & Sub-Activities • Effective Dates • Contract Status (active, inactive, closed, etc)

L

3.3.16 The system should have the ability to link service agreements to an external service provider. L

3.3.17 The system should have the ability to link financial commitments to service agreements/contracts. H

38




3.3.18 The system should support amendments to a service agreement without needing to re-enter the original data. L

3.4 Functional Area 4 – Notification / Alert Management

Description: Notifications are system or user generated notices that a specific action is required or has taken place on a service which is part of the user’s workload. The system must be able to internally manage the creation, maintenance and delivery of notifications which could include delivery through a dashboard, pop up or notification work list. The system must not send notifications via email. The system must not allow notifications to prevent the completion of tasks in the system.




3.4.1 The system should have the ability to manage both user created and system generated notifications. H

3.4.2 The system should have the ability to manage notification types including but not limited to:

• Upcoming Activity Notification: Notifications related to activities for a service which are coming up (e.g., Risk assessment review every 6 months, etc.)

• Overdue Activity Notifications: Notifications related

to activities for a service which are overdue (e.g., safety plan completion overdue, etc.)

• Conditional Notification: Notifications generated based on a change in information of a service or

H

39




service recipient (e.g., a child moves location)

3.4.3 The system should provide the ability for the user to sort notification by type or due date. H

3.4.4 The system should have the ability to define who should receive the notifications based on service provider role and relationship. H

3.4.5 The system should have the ability to notify all system users of critical information not associated with a service recipient’s file (e.g. system maintenance, changes to legislation, etc.). L

3.4.6 The system should have the ability to transfer notifications (e.g., between workers) when the service is transferred. H

3.4.7 The system should have the ability for an authorized user or configuration administrators to enable access to the view of one user’s “home page” and/or notifications to another user either on an ongoing or one time basis.

H

For example when one manager is covering for another manager.

3.4.8 The system should have the ability to automatically deactivate notifications after a specified period of time or when a specific action has taken place (e.g., documents are received or risk assessment is completed).

M

Automated deactivation after a specified time frame would only occur for very limited non-critical notifications.

3.4.9 The system should have the ability to set up notifications on a recurring basis. M

3.4.10 The system should have the ability to generate notifications upon service closure. M

3.4.11 The system should not allow users to delete critical, system-set notifications. These notifications are only deleted when pre-specified actions are completed on the system. (e.g., system sets a notification to complete a risk assessment or

M

40




safety plan based on the provincial standard for completion when the activity has been completed the notification is automatically removed).

3.4.12 The system should provide the ability to allow the user to manually set a notification for situations not covered by system generated notifications. Users must be able to enter their own notification text and set the number of days in the future the notification must appear on the user's notification list.

M

3.4.13 The system should provide the ability to allow users to dismiss/remove non-critical or user set notifications to a different time/date at the batch or individual level. H

3.4.14 The system should provide a method for users to view all notifications for his/her entire workload. A supervisor must be able to see all critical notifications for all workers assigned to him/her.

H

3.4.15 The system should terminate and remove all applicable notifications when a service is closed H

3.4.16 The system should provide the ability for supervisors to be notified when services of a particular status have had no activity for a specified period of time. M

3.5 Functional Area 5 – Schedule / Task (Keep in View) Management

Description: The system must be able to manage mandatory and user defined keep in views for CYFS staff.

41




3.5.1 The system should have the ability for mandatory keep in views to be defined by a configuration administrator. H Mandatory keep in views could include but

are not limited to:

• Risk Assessment • Safety Plan • Family Centred Action Plan

(FCAP)

3.5.2 The system should have the ability for the user to define additional keep in views to support the management of service provider activities. M

Service Provider activities could include:

• Reviews with service recipients • Court hearings

3.5.3 The system should have the ability for the user to define recurring “keep in views”

M

3.5.4 The system should have the ability to link a keep in view to a service.

H

3.5.5 The system should have the ability to view keep in views as a date ordered list or as a calendar.

H

3.5.6 The system should have the ability to filter keep in views by KIV type, service provider, service recipient and date.

M

3.5.7 The system should have the ability to print KIV lists for different filter selections

H

3.5.8 The system should have the ability for supervisors to view the KIVs of their staff.

H

3.5.9 The system should have the ability for a user covering for another user to see the KIVs of the other user.

H

3.5.10 The system should have the ability to schedule and manage (add, update, delete) service recipient appointments. The system should allow the staff to:

• Establish his/her availability for a minimum of 3 months into the future

• Display the scheduled appointments

L

42




• Display availability for new appointments.

3.5.11 The system should have the ability to provide or integrate with calendar functionality such as Microsoft Outlook (e.g. notifications, tasks, calendar sharing, appointment acceptance, etc.).

L

3.5.12 The system should have the ability to categorize and classify appointment types (e.g., work tasks, service recipient tasks, etc).

L

3.5.13 The system should have the ability for the system users to set privacy parameters associated with tasks or appointments in their calendar.

L

3.5.14 The system should have the ability to associate appointments and attendance with the service recipients in a service.

L

3.5.15 The system should have the ability to open the service recipient service from the KIV item.

L

3.5.16 The system should have the ability to see an appointment from the service recipient service or the appointment schedule.

L

3.5.17 The system should have the ability to produce an appointment schedule (e.g., all service recipients scheduled for an interview on a particular day).

L

3.5.18 The system should have the ability to produce a task list (e.g., all active “to do” items).

L

3.5.19 The system should have the ability for the user to remove user defined KIVs that are no longer applicable.

H

43




3.5.20 The system should have the ability to remove all applicable future KIVs when a service is closed

H

3.6 Functional Area 6 – Workflow / Rules Management

Description: The workflow functionality must support a common path and structures based on the business processes where appropriate, determined by CYFS. The system workflow must enable flexibility to off-ramp and circumvent or flag system level approvals to enable service providers to effectively deliver services and continue to support their service recipients. Where segregation of duties and delegation of authority are required (i.e., financial processes) the system must provide a more rigid approval workflow.




3.6.1 The system should have the ability for a user to flag a non financial activity as approved and indicate the approver. This may include but is not limited to:

• Approval of a risk assessment • Approval of a safety plan

H

3.6.2 The system should provide the ability to create a list of flagged approvals and send a weekly approval report notification to supervisors for follow up and review. H

3.6.3 The system should provide the ability to enforce an approval workflow for all financial payment types including:

• Service authorizations • Financial Requests • On-demand Payments • Recurring payments • Grants

H

44




• Bursaries • Etc.

3.6.4 The system should have the ability to specify alternate paths or branches in the financial workflow steps depending on business rules. H

3.6.5 The system should have the ability for a financial workflow step to initiate a sub-workflow based on business rules. M

3.6.6 The system should have the ability for a financial workflow step to loop back to a previous step based on a business rule or user input. M

3.6.7 The system should have the ability to escalate a particular financial workflow step or activity for completion based on business rules. M

3.6.8 The system should have the ability for an authorized user or configuration administrator to delegate a financial workflow item from one user to another. H

3.6.9 The system should have the ability for an authorized user or configuration administrator to delegate multiple workflow items from one user to another. H

3.6.10 The system should have the ability to manage (create, review, update, delete, transfer etc.) notifications and KIVs for a variety of financial workflow steps and items. M

3.6.11 The system should have the ability to define a delegation of authority for specific workflow tasks. H

Financial Assistance Officer creates Service Authorization; a supervisor approves it.

45

3.7 Functional Area 7 – Financial Management

Description: The system must be able to initiate multiple types of financial transactions and seamlessly integrate with Government’s financial management system to complete a financial transaction. The system must be able to link a payment to a benefit type, a payment to a payee, a payment to a service recipient and a payment to a program/service.




Accounts Payable

It is anticipated that the new solution will be tightly integrated with Government’s Financial Management Solution (FMS) to complete payments including the issuance of cheques and electronic fund transfers. The new solution should be able to initiate the payment transaction and receive detailed payment status information from FMS.

Currently there are five payment types within CYFS.

1. Service Authorization – Invoice driven payments which are either one time or multiple.

2. Financial Request – Non invoice driven payments (sometimes a receipt is provided) either one time or reoccurring.

3. On Demand Payments – Emergency payments.

4. Grants – Annual payments provided to external service providers.

5. Bursaries – Annual payments

46




made to service recipients

3.7.1 The system should have the ability to support a hierarchical categorization of codes for a sub Chart of Accounts.

H The hierarchical categorization of major elements should align with Government’s chart of accounts to provide the ability for easy rollup.

3.7.2 The system should have the ability to maintain an accounts payable sub ledger that tracks payables at the individual and group service recipient level for a specific benefit type. H

3.7.3 The system should have the ability to transfer an approved payment from one payee to another (e.g. when a child with a child care subsidy changes child care centres).

M

3.7.4 The system should have the ability to print a cancelled authorization to send to the payee as a cancellation notice. H

3.7.5 The system should have the ability to print any deductions (e.g. parental fee) on the financial authorization. H

3.7.6 The system should have the ability to spread a single family based deduction over multiple children and If one child’s payment ends generate a notification to the financial service provider to adjust the remaining payments.

H

3.7.8 The system should have the ability to provide a financial summary for each service recipient and service including:

• Amounts paid • Benefit type • Date • Status

H

For example if a social worker is inquiring on the payment status of a specific service recipient they should be able to search on either the service recipient or the service to view a summary financial profile.

3.7.9 The system should have the ability to provide a financial summary for each service recipient across services including: H

47




• Amounts paid • Benefit type • Date • Status

The system should have the ability to track and monitor payments across the CYFS organization for each region, program, service, benefit type, service recipient and payee. H

3.7.10 The system should have the ability to track payment status (e.g., completed, pending, stopped) and provide a payment status update. H

3.7.11 The system should have the ability to stop, hold, suspend or cancel all payments to service recipients. H

3.7.12 The system should have the ability to make replacement payments if required by the authorized authority. H

3.7.13 The system should have the ability to link a payment, invoice and/or receipt to a service recipient, service and payee. H

3.7.14 The system should have the ability to link a social worker’s assessment / payment requirement to a payment authorization. H

3.7.15 The system should have the ability to transmit payment information individually or by batch to Government’s Financial Management system. H

Government currently uses Oracle EBS 11i. There is an initiative underway to update the FMS solution to Oracle R12.

3.7.16 The system should have the ability to view variance of commitments and disbursements for any level of CYFS’ Chart of Accounts H

3.7.17 The system should have the ability to setup and maintain vendor (payee) information in the system. H

It is possible that a vendor could be a service recipient or a payee.

48




3.7.17.1 The system should have the ability to create and suspend a payment in real time or in advance using effective dates. H

3.7.18 The system should have the ability to track effective and end dates for business rules and configure rates and implement changes en mass. H

3.7.19 The system should provide the ability for authorized users to configure benefit rates. H

3.7.20 The system should provide a tool to automatically calculate benefits to a payee based on selected benefit type.

H

The tools could be used to calculate amounts including:

• Child Welfare Allowance • Subsidies • Special Needs Assessment

While the system should automate entitlements where appropriate it should also have the flexibility for a user to be able to override financial entitlements as required.

3.7.21 The system should have the ability to calculate multiple benefit types in a single financial request H

3.7.22 The system should provide an eligibility rules engine for various financial benefit types that can be maintained by non-technical CYFS staff with authorized access. H

3.7.23 The system should automatically provide the eligible benefit amount to a service recipient based on pre populated and predefined benefits according to CYFS policy and legislation.

H

For example if a child is 2 years old and the family requires child care allowance the system should automatically calculate the maximum benefit eligibility.

49




3.7.24 The system should have the ability to notify the appropriate users when a maximum amount per CYFS policy is used for a specific calendar year.

H

For example if policy indicates that a caregiver can receive up to 30 days financial assistance for respite vacation, the system should have the ability to notify an FAO if trying to pay over the 30 day limit.

The system should have the ability to merge/transfer overpayments between a service recipient’s services within and across programs. H

3.7.25 The system should have the ability to easily recreate any type of payment by copying over relevant payment information from a previous payment transaction. H

3.7.26 The system should have the ability to create an invoice driven service authorization for an individual or group service recipient. H

3.7.27 The system should have the ability to enable a service authorization to span over government’s fiscal year end.

H

It is anticipated that when a service authorization occurs over separate fiscal years the system would automatically generate two service authorizations, one up to March 31st and the other for the new fiscal year until expiry.

3.7.28 The system should have the ability to automatically assign a service authorization number to a service authorization. H

3.7.29 The system should have the ability to cap a service authorization at a predefined benefit threshold and notify a Financial Service Provider when the service authorization has reached the threshold.

H

3.7.30 The system should have the ability to easily recreate a service authorization from an existing one pre populating any relevant H For example when a Service Authorization

expires or reaches a threshold and a new

50




information. services authorization is required the FAO should be able to easily recreate a new service authorization using relevant information from the previous authorization.

3.7.31 The system should have the ability to pay various benefit types to a single vendor with one service authorization or payment request. H

3.7.32 The system should have the ability to reconcile invoices against a service authorization. H

3.7.33 The system should have the ability to create reoccurring payments for a single financial request H

3.7.34 The system should have the ability to extend a reoccurring payment. H

3.7.35 The system should provide the ability to have both rules driven and user defined payment schedules to create reoccurring payment schedule for an individual or group service recipient. H

3.7.36 The system should have the ability to automatically stop a reoccurring payment when a service that the payment is linked to, is closed. H

3.7.37 The system should have the ability to automatically adjust a payment amount if there is a change in circumstance (e.g., child’s age changes and a recalculation of benefit is required).

H

For example if a child is in foster care, the foster family receives reoccurring payments on the 1st and 16th of the month. If the child leaves the home the system should be able to recalculate the benefit to the foster family.

3.7.38 The system should have the ability to provide a mechanism to H

51




print cheques in various CYFS offices across the province.

3.7.39 The system should provide edit controls to help prevent data entry errors.

H

For example if a payment is setup for Jan 1, 2011 and an FAO mistakenly enters Jan 1, 2010, the system should prompt the FAO before initiating the transaction.

3.7.40 The system should maintain a history of all financial transactions including but not limited to:

• Date of transaction • Service Recipient • Payee • Benefit Type • Service

H

3.7.41 The system should have the ability to initiate annual grants and bursaries. H

3.7.42 The system should have the ability to prevent the user who creates a vendor from initiating a payment to a vendor. H

3.7.43 The system should have the ability to initiate annual grants and bursaries. H

3.7.44 The system should have the ability to prevent the user who creates a vendor from initiating a payment to a vendor. H

3.7.45 The system should provide the ability to enforce approval of a payment by an authorized user before payment is processed H

3.7.46 The system should have the ability for an authorized user to approve a payment individually or by batch. H

3.7.47 The system should provide the ability to search for any payment based on any payment related field. H

52




3.7.48 The system should have the ability for authorized users to make non-financial updates to a service authorization with a comment explaining the change.

H

One of the current system pain points is that when a service authorization is created a user is unable to update any text fields if there was a typo made or if the authorization is for an appointment and the date of the appointment is changed.

3.7.49 The system should have the ability to reconcile payments against a financial approval. H

For example, payment of a foster parent for provision of weekend respite.

3.7.49.1 The system should have the ability to print ambulance/dental cards and link them to the appropriate financial system.

H CYFS issues ambulance/dental cards to children and youth residing in residential services. The Department of Health is responsible for paying for the service. The system must generate a number on the card (piece of paper) that the supplier can use to submit the bill.

Accounts Receivable

It is anticipated that the new solution will be tightly integrated with Government’s Financial Management solution to manage accounts receivable.

The new solution should be able to indicate if there has been an overpayment to a service recipient or payee and initiate an A/R transaction to FMS A/R Module.

The Department is currently in the process of defining how the collections and recoupment process will be completed for each program.

3.7.50 The system should have the ability to maintain an Accounts Receivable (A/R) sub ledger that tracks receivables at the individual and group service recipient level for a specific

H

53




benefit type paid to a specific payee.

3.7.51 The system should have the ability to tightly integrate with Government’s FMS A/R module to maintain accounts receivable information. H

3.7.52 The system should have the ability to setup payments in arrears to help reduce overpayments. H

3.7.53 The system should have the ability to collect on an overpayment to a payee. H

3.7.54 The system should have the ability to provide a historical point and time record of A/R balances at the individual service recipient level. H

3.7.55 The system should have the ability to record overpayments and underpayments against an individual/group service recipient and/or payee. H

3.7.56 The system should have the ability to track recoveries made against an overpayment H

3.8 Functional Area 8 – Budget Management

Description: The system should be able to either integrate with a corporate budgeting solution or manage budgets at various Chart of Account levels. The Budget functionality must also manage budgeted versus actual encumbrances and enable CYFS to track budget spending on a standardized and ad-hoc basis.




54




3.8.1 The system should have the ability to manage encumbrances against approved annual budget.

H

Government is currently in the process of implementing Oracle project costing module which could be used to monitor the program, service and benefit type encumbrances against an approved budget.

3.8.2 The system should have the ability to manage program budgets by CYFS’ organizational structure including program, service and benefit type. H

3.8.3 The system should have the ability to manage program budgets by CYFS’ geographical structure including region, district and zone. H

3.8.4 The system should have the ability to manage program budgets by electoral district. H

3.8.5 The system should have the ability to track encumbrances against a service authorization.

H

For example if a service recipient has an approved service authorization the system should be able to track the encumbrances against the approved SA.

3.8.6 The system should be able to recognize that a payment has been made and that all systems (Oracle Financial) are updated, and display information to the end user. H

3.8.7 The vendor should outline how they are able to support the integration to a major budgeting and forecasting system which is able to produce budgets at the individual service recipient level..

H

55

3.9 Functional Area 9 – Document Management

Description: The system must enable effective management of both electronic and paper records. Document management includes the ability to link hardcopy and paper documents to a service(s), and integrate with a centralized document management solution.




3.9.1 The system should have the ability to support attaching electronic documents to services (e.g. scanned signed documentation, paper completed risk assessments, court documents, etc).

H

3.9.2 The system should have the ability to support attaching electronic documents to service recipient profiles (e.g. photos, birth certificates, etc). H

3.9.3 The system should have the ability to manage version control of attached documents. H

3.9.4 The system should have the ability to store documents and manage access in a secure manner.

H

The Department is currently evaluating alternatives for document management. It is possible that in the future the ISM will need to integrated with a document management solution (TRIM) but should also have a self sufficient capability for document management.

3.9.5 The system should have the ability for system users to view attached documents from multiple points in the system. H

3.9.6 The system should have the ability to attach documents from multiple formats (e.g., MS Word, XLS, PPT, PDF, RTF, JPG, BMP, etc). H

3.9.7 The system should allow a user to print an entire individual service package from a centralized point. The system should also provide a checklist of which services/documents the user

H

56




would like to print or not print.

3.9.8 The solution should have a secure capability to manage electronic copies of paper documents and to create and manage associated meta data. M

3.9.9 The solution should have the ability to track the physical location of paper documents. H

3.10 Functional Area 10 – Forms and Correspondence Management

Description: The system must enable effective management of various forms for service delivery and correspondence between CYFS and service recipients and other participants. The system should have the ability to generate various types of letters and correspondence, and maintain document templates.




3.10.1 The system should have the ability for non-technical business resources to manage (create, review, update, delete) templates (e.g. forms, letters, agreements, assessments, etc) with appropriate permission.

H

3.10.2 The system should have the ability to allow CYFS Service Providers to correspond with Service Recipients and to track/log the correspondence.

L

3.10.3 The system should have the ability to record the date and time of the correspondence and retain a copy in the system. M

3.10.4 The system should have the ability to reprint any correspondence generated by the system (e.g. pre-formatted M

57




letters, notifications). The system should record the date and time of the reprint.

3.10.5 The system should have the ability to auto-generate and pre populate correspondence or forms based on business rules (e.g. age trigger, set dates, etc).

M

3.10.6 The system should have the ability to include graphics within the templates (e.g. signatures, CYFS logos, etc.) which can be changed as required by non-technical users with appropriate permissions.

M

3.10.7 The system should have the ability to control versions of templates to ensure historical data can still be viewed or printed based on old template versions.

M

3.10.8 The system should have the ability to transmit (email, fax) the document as required. M

3.10.9 The system should have the ability to print all letters correspondence and templates H

3.10.10 The system should have the ability to print envelopes or labels. L

3.11 Functional Area 11 – Campaign Management

Description: The system should be capable of managing communication and marketing campaigns which includes the ability to create, update, delete and review a list of contacts. The following items outline the requirements for the system to allow CYFS to manage communication and marketing campaigns. Requirements include functionality to support lists, campaigns, and responses / inquiries.

58




3.11.1 The system should have the ability to manage lists of contacts and profiles for email and correspondence management. L

3.11.2 The system should have the ability to provide email campaign functionality that would be able to track the response rate for outbound emails to selected contacts.

L

3.11.3 The system should have the ability to provide functionality for general marketing and event campaigns. L

3.11.4 The system should have the ability to compare success of the marketing campaign for a particular program. For example: compare the date of the campaign for a particular service and track the program/service utilization for set time duration.

L

4.0 FUNCTIONAL AREA SUMMARY

Functional Areas

Service Recipient and Participants Management: The solution must provide a 360 degree view of the service recipient and participant including all of the interactions the service recipient or participant has across CYFS programs and services. An individual or group can be a service recipient. The solution should support creation, update, review merging and deletion of service recipient and participant profiles, provide business rules to eliminate duplication of records, allow for efficient search methods and enable appropriate up-to-date access of service recipient and participant information by authorized service providers.

Service Management: The system must provide the ability to define and manage a variety of service type definitions which are composed of activity lists, key information and business rules based on program policy. The system must provide the ability to initiate a service for a service recipient(s). Services are provided in a common service framework which includes request, screen, assess, plan, service and monitor, review, and close stages. The solution must have the ability to provide a 360 degree view of the service including, who is involved in the service and the detailed service history. The solution should also

59

Functional Areas

provide functionality to track the service progression and all involved participants across the service stages.

Service Provider Management: The system must provide the ability to manage and support Internal (CYFS Staff) and External (Contracted) service providers. The system must be able to link service providers across multiple services and assist in the assignment of services to service providers to give a full view of the CYFS work effort. The system must provide tools such as Keep in Views, Notifications, Alerts and “My load” views to support the activities of internal service providers. The system must also be able to effectively manage service agreements and contracts between CYFS and external service providers.

Notification / Alert Management: Notifications are system or user generated notices that a specific action is required or has taken place on a service which is part of the user’s workload. The system must be able to internally manage the creation, maintenance and delivery of notifications which could include delivery through a dashboard, pop up or notification work list. The system must not send notifications via email.

Schedule / Tasks (Keep In View) Management: The system must be able to manage mandatory and user defined keep in views for CYFS staff. The system should also be able to interface with Government’s email (Microsoft Outlook) to manage a task list, schedule and manage service recipient appointments.

Workflow / Rules Management: The workflow functionality must support a common path and structures based on the business processes where appropriate, determined by CYFS. The system workflow must enable flexibility to off-ramp and circumvent or flag system level approvals to enable service providers to effectively deliver services and continue to support their service recipients. Where segregation of duties and delegation of authority are required (i.e., financial processes) the system must provide a more rigid approval workflow.

Financial Management: The system must be able to initiate multiple types of financial transactions and seamlessly integrate with Government’s financial management system to complete a financial transaction. The system must be able to link a payment to a benefit type, a payment to a payee, a payment to a service recipient and a payment to a program/service.

Budget Management: The system should be able to either integrate with a corporate budgeting solution or manage budgets at various Chart of Account levels. The Budget functionality must also manage budgeted versus actual encumbrances and enable CYFS to track budget spending on a standardized and ad-hoc basis.

60

Functional Areas

Document Management: The system must enable effective management of both electronic and paper records. Document management includes the ability to link hardcopy and paper documents to a service(s), and integrate with a centralized document management solution.

Forms and Correspondence Management: The system must enable effective management of various forms for service delivery and correspondence between CYFS and service recipients and other participants. The system should have the ability to generate various types of letters and correspondence, and maintain document templates.

Campaign Management: The system should be capable of managing communication and marketing campaigns which includes the ability to create, update, delete and review a list of contacts. The following items outline the requirements for the system to allow CYFS to manage communication and marketing campaigns. Requirements include functionality to support lists, campaigns, and responses / inquiries.

5.0 REPORTING REQUIREMENTS

Reporting requirements identify what reports the application and/or system must be able to manage. It is anticipated additional program specific reporting requirements will be identified during detailed design.

5.1 General Reporting


H - High M – Medium L – Low.


5.1.1 The system should have the ability to generate reports based on geographical location including province, region, zone district, etc in alignment with CYFS’ organizational structure and electoral district.

H

5.1.2 The system should have the ability to generate reports scoped by role and responsibility (executive director, director, supervisor, etc.) in alignment with CYFS’ organizational

H

61




structure.

5.1.2.1 The system should have the ability to generate reports based on program area, program and service. H

5.1.3 The system should have the ability to generate both predefined and ad hoc reports and perform on-demand data analysis.

H

5.1.4 The system should have the ability to export summary and detail statistical data to other tools (SAS, Cognos). H

5.1.5 The system should have the ability to generate reports in multiple formats (PDF, XLS, HTML). H

5.1.6 The system should have the ability to generate reports from the information gathered in various functional components of the service stages (e.g., request, screen, assess, etc) including number of each service type at each stage, number closed by reason code, etc.

H

5.1.7 The system should have the ability to cross tabulate data analysis results and roll them into a consolidated result (e.g., number of types of services closed by closure reason, service recipient location & age group).

H

5.1.8 The system should have the ability to limit report access based on the user permissions. H

5.1.9 The system should have the ability to provide reporting across divisions and programs on key entities such as Service Recipient, Service, Service Provider, Invoices, Payments, Receivables, etc.

H

5.1.10 The system should have the ability to generate consolidated detailed reports per service recipient across all services (e.g. H

62




all activity notes for a particular service recipient across all active and/or closed services).

5.1.11 The system should have the ability to provide a Data Dictionary which reflects the relationship between data elements to assist super users in creating new reports.

M

5.1.12 The system should provide the ability for non technical users to easily construct their own reports. H

5.1.13 The system should have the ability to customize standard inquiries and reports based on user security level. M

5.1.14 The system should have the ability to generate graphical representations (e.g. pie charts, bar graphs, etc.). M

5.1.15 The system should have the ability to copy/paste data selected from electronic source documents or from within the system into reports, templates, correspondence, etc.

M

5.1.16 The system should have the ability to maintain historical data for reporting or exporting. H

5.1.17 The system should have the ability to report on data that is current in real time or near real time while minimizing the impact upon other users of the application.

H

5.1.18 The system should have the ability to search and view the complete list of available pre-defined reports (with descriptions) that exist on the system.

H

5.1.19 The system should have the ability to report on data entered during a specific date range. H

5.1.20 The system should have the ability to provide detailed individual service reports (e.g. for use in appeals, court review, H

63




disclosures, etc.).

5.1.21 The system should have the ability to record and report on requests for information from external sources. H

5.1.22 The system should have the ability to create a consolidated report consisting of both current information in ISM and historical data stored in other external systems

M

5.1.23 The system should have the ability to distribute reports through various distribution channels, email, push to a dashboard, store online, etc.

M

5.2 Management Reporting




5.2.1 The system should have the ability to provide service provider caseload statistic reports (e.g., # of service recipients, # of active services, # of each activity type, # of new services, # of closed services, etc.) for a specified data range or an as date

H

5.2.2 The system should have the ability to record and report volume counts at the request stage for a variety of inquiries and information sharing activities provided to individuals who may/may not register with CYFS.

At a minimum, volume counts are required:

• On a daily, weekly, monthly, quarterly and annual basis

H

64




• For a specified date range • By staff member, worksite, area and region • By Type of Contact • Request Type

5.2.3 The system should have the ability to capture and quantify the client’s “success” according to CYFS “service standards” or other outcome measurements (e.g., repeat interactions with CYFS).

H

5.2.4 The system should have the ability for a user to create reports to analyze and track the performance of programs and service delivery models against key program indicators defined by the department.

H Key program indicators could include:

• Key activities completed • Length of time between particular

activities • Length of time on a waitlist

5.2.5 The system should have the ability to provide a dashboard capability to report on and/or monitor key program/service information and events (e.g. worker tasks as target dates).

M Dashboard access would depend on user requirements and permissions with user ability to customize dashboard contents.

5.2.6 The system should have the ability to measure performance against specific service standards and produce monitoring reports on service standards exceptions, for example:

• Risk assessment completed in X # of days, not completed in X # of days

• Annual review completed in X # of days , not completed in X # of days

• Site Visit completed in X # of days (based on criticality), etc.

H

5.2.7 The system should have the ability to report on client demographics including age, location, gender, etc. H

5.2.8 The system should have the ability to generated detailed statistics on each different type of service recipient profile. H

65




5.2.9 The system should have the ability track and create reports to analyze, track and monitor user performance against pre-defined standards and other work activity indicators or work flows at a user and aggregate level

H Example number of visits to foster homes by a social worker in a month, number of visits completed by all social workers in a zone in a month.

5.3 Financial Reporting




5.3.1 The system should have the ability to report on financial commitments over a period of time.

H Commitments could include bursaries, grants, subsidies, other one time payments.

5.3.2 The system should have the ability to roll up all financial reports by various combinations of geographical area (e.g., region, zone, electoral district).

H

5.3.3 The system should have the ability to provide variance analysis of commitments and disbursements at a service recipient level for any level of chart of accounts.

H

5.3.4 The system should have the ability to provide financial reporting, including period end payment summaries for service providers, clients or other payees.

H

5.3.5 The system should have the ability to produce cheque stubs with detailed payment information. H Payments will be made through FMS but

Siebel will be required to develop a “Cheque Stub” based on the payment information that will be mailed to the cheque recipient electronically outlining the

66




benefits on the payment. E-mail will be the preferred form of mail but a pare version will have to be mailed to people with an e-mail address.

The cheque stub from FMS will not contain benefit information (maximum description length is 18 characters).

5.3.6 The system should have the ability to report the financial disbursements per service recipient, for each benefit type across all relevant payees.

H

5..3.7 The system should have the ability to report the financial disbursements per program area, program and service for each benefit type

H

5.4 Child Protection, Youth Services and In Care Reporting




5.4.1 The system should have the ability to generate status summaries on medium/high risk protective intervention services, including risk level, risk rating, completion and upcoming dates of key activities (e.g. face to face meeting, Safety Assessment, Risk Assessment, FCAP).

H

5.4.2 The system should have the ability to produce statistics on the number of times a child has been moved while in placement. H

5.4.3 The system should have the ability to produce statistics on the number of times a child has moved with his/her family in the H

67




past year.

5.4.4 The system should have the ability to produce statistics on the number of reoccurrences of maltreatment after service closure.

H

5.4.5 The system should have the ability to report the number of additional referrals that are made on active cases. H

5.4.6 The system should have the ability to report on the number of adverse events by age and service type. H An adverse event could include

occurrences of serious injury or death.

5.4.7 The system should have the ability to report how many children are in care in each placement type, how long they have been in care, how many of each type of permanency plan goal.

H

5.4.8 The system should have the ability to report details on the removal of a child including:

• Length of time between removal and hearing date. • Length of time between removal and final decision on

child’s custody • Reason for removal (child removed at birth,

inadequate supervision) • Location of removal

H

5.4.9 The system should have the ability to report number of siblings placed together, number placed apart. H

5.4.10 The system should have the ability to report on number of youth in each youth services type, number in each placement type, number of each previous involvement type, number dropped out of youth service.

H

5.4.11 The system should have the ability to perform data analysis linking parental attributes (e.g. age, marital status, and living H

68




situation) with children entering care/custody or in need of protection and reasons for removal.

5.4.11.1 The system should have the ability to perform data analysis linking child attributes with need for protective intervention, risk rating, or entering care/custody

H

5.4.12 The system should have the ability to report on how many children are receiving protection services by allegation type. H

5.4.13 The system should have the ability to report on number and types of referrals of both children and parents to external services either when screened out or during on-going services.

H

5.4.14 The system should have the ability to report on number of children/youth back In Care or Youth Services due to adoption breakdown.

H

5.5 Caregiver and Residential Reporting




5.5.1 The system should have the ability to track the number of children/youth in a home, number of vacancies, number over the limit, per reason type, with and without specific approval as of a particular date and for a specified time period.

H

5.5.2 The system should have the ability to generate a report of the children/youth in each home including the Child/Youth profile information (age, gender, date of entry, etc.).

H

69




The system should have the ability to generate an historical report of children and youth placed in the home within a specified date range, including child/youth name and, dates of entry and exit.

H

5.5.3 The system should have the ability to report the number of each type of approved home (placement type) and length of service.

H

5.5.4 The system should have the ability to report for a specific time period, the number of applicants of each type, number withdrawn, number not approved, number waitlisted, number in process, number with interim approval, number approved, etc.

H

5.5.5 The system should have the ability to report the number of relative/significant other homes that applied to become non-relative.

H

5.5.6 The system should have the ability to report the number and type of quality of care incidents. H

5.5.7 The system should have the ability to report the number and type of investigations, number and type of investigation resolutions.

H

5.6 Adoptions Reporting




70




5.6.1 The system should have the ability to track statistics on specific demographics of adopted children or children awaiting adoption, including, age, gender, location, time in care, date relinquished from hospital, etc.

H

5.6.2 The system should have the ability to track statistics on the commitments of the adoption subsidy including, amount given, types of services, additional requests, etc.

H

5.6.3 The system should have the ability to report on and provide trend analysis of adoption placements for children based on age range, gender, adoption type (e.g., inter provincial, inter country, step parent/relative, etc.).

H

5.6.4 The system should have the ability to track number of adoption applicants not approved, withdrawn, etc. H

5.6.5 The system should have the ability to track number of times a child not accepted by a matched family. H

5.6.6 The system should have the ability to report on length of time child is in the queue before being placed with an adoptive family.

H

5.7 Child Care Services Reporting




5.7.1 The system should have the ability to perform detailed data analysis and reporting on child care centre and child care home profile and service information including age ranges, number of homerooms, types and numbers of spaces, number

H

71




and type of staff, etc.

5.7.2 The system should have the ability to report on annual child care centre/home enrollment and staffing statistics. H

5.7.3 The system should have the ability to report on number and types of warnings, violations and investigations and corresponding visits and consults, resolution type and time period by child care centre/home.

H

5.7.4 The system should have the ability to report on number and location of inquiries regarding new licenses and number of meetings and consults involved.

H

5.7.5 The system should have the ability to report on the number of new, ongoing, closed inclusion services by type, duration, hours of support.

H

5.7.6 The system should have the ability to report on child specific inclusion services including age range, centre/home, full/part time attendance.

H

5.7.7 The system should have the ability to report on capacity initiatives, status, spaces and related financial commitments. H

5.7.8 The system should have the ability to perform detailed reporting on child care subsidies including subsidy reason, single/two parents, child(ren) age range, gender, full/part time attendance, if income tested, full/partial subsidy, centre/home, transportation, etc.

H

5.7.9 The system should have the ability to track and report on Family Resource Program statistics contained in the annual reports.

H

72




5.7.10 The system should have the ability to report on bursaries and ELCC supplements for individuals including counts, certification category & level, amounts, by geography and historical for a particular individual.

H This information may be captured through FMS. If it is captured in ISM, the requirement is high.

5.8 Youth Corrections Reporting




5.8.1 The system should have the ability to track statistics on group home admissions and releases, daily, monthly, etc. H

5.8.2 The system should have the ability to track statistics on group home occupancy, vacancy, categories of youth placed versus categories of youth the group home is approved for.

H

5.8.3 The system should have the ability to report on number of youth currently and historically per sentence type and per custody/non custody status.

H

5.8.4 The system should have the ability to export applicable data to Canadian Centre for Justice Statistics - National Justice Statistics Initiative.

H

5.8.5 The system should have the ability to track monthly statistics on number of new, closed, active at start of month, active at end of month, cases per custody/non-custody status.

H For example open custody, community supervision, probation etc.

5.8.6 The system should have the ability to track statistics on daily average per month of clients in each type of custody/non- H

73




custody status, broken out by gender and age range.

5.8.7 The system should have the ability to report on number of service recipients per risk assessment rating broken out by gender and age range.

H

5.8.8 The system should have the ability to report on number of open Extrajudicial Sanctions (EJS) services for each EJS Committee.

H

5.8.9 The system should have the ability to report on number of closed EJS services for each EJS Committee per specified time period broken out by youth completion status (Completed / Not Completed).

H

5.8.10 The system should have the ability to track monthly statistics on number of EJS referrals, completions, returns to crown attorney for each EJS committee by youth gender.

H

6.0 INTERFACE / INTEGRATION REQUIREMENTS

Interface Requirements identify what information is needed to ensure that the system will communicate properly with external components.




6.0.1 The solution should have the ability to support leading industry standard integration tools such as Oracle Fusion, Websphere, TIBCO, etc.

H These integration tools will be used to build the required system interfaces indicated in this section and any future interface requirements for the solution (e.g., Panorama – a national health surveillance

74




system).

6.0.2 The system should have the ability to provide a secure interface and viewer to the Youth Corrections Management System (YCMS) to allow authorized users to view specified information on shared service recipients.

M Specified information may include:

• Suicide assessments • Incident reports • Other reports or assessments

completed while a shared service recipient is in secure custody

6.0.3 The system should have the ability to interface with the Department of Justice offense library to receive updates on offence and statute details.

H

6.0.4 The system should have the ability to allow users to access the Human Resource Labour and Employment (HRLE) CAPS viewer (or future income support solution) through a URL in the ISM.

M The purpose of this viewer is to view financial benefits and demographic information on shared service recipients.

6.0.5 The system should have the ability to integrate with NLCHI’s client registry enterprise viewer to share recent client demographic and profile information including.

• Name • Address • Gender • MCP Number

H

CYFS is currently in the process of drafting a Memorandum of Understanding (MOU) with NLCHI for data sharing.

NLCHI uses HL7 v3 standard.

6.0.6 The system should have the ability to send and receive demographic and profile updates from NLCHI’s Client Registry on a set schedule.

H The integration between NLCHI and CRMS is bidirectional with merge capability. The enterprise view is a custom built application which is based on Websphere.

75




NLCHI uses HL7 v3 standard.

6.0.7

The system should have the ability to integrate with Government’s Panorama system.

L The Government has yet to release Panorama but it is expected that the new ISM solution will require flexibility to integrate with Panorama using industry standard integration tools and technologies when the system is live.

6.0.8

The system should have the ability to provide a link or view into CRMS to view service information on shared service recipients.

H CYFS is in the process of drafting an MOU with the Regional Health Authorities which will address information sharing. Access is dependant on an MOU agreeing to information sharing.

6.0.9 The system should have the ability to Integrate with Government’s records management solution (TRIM) to store and retrieve electronic documents in real time.

H

6.0.10 The system should have the ability to integrate with Microsoft Outlook. L CYFS’ Outlook calendar and tasks lists

should be accessible in a user’s homepage dashboard.

6.0.11 The system should have the ability to integrate with various types of document creation software (e.g., MS Word, Excel, PDF)

H Users should be able to complete, review and update external forms at multiple points in the system. For example a social worker should have the ability to initiate and complete a PDF risk assessment form from a service activity list.

6.0.12 The system should have the ability to integrate with the various FMS modules (Accounts Payable, Accounts Receivable, Cash Management, Project Costing, Loans and General Ledger) of Government’s Financial Management

H Government is currently undertaking a project to upgrade their existing FMS system to Oracle R12.

76




System (currently Oracle 11i).

6.0.13 The system should have the ability to extract budgeting information from Oracle Hyperion Public Sector 12 and be able to update actuals stored in the ISM solution.

L

6.0.14 The system should have the ability to integrate with the Government’s common IT services (backup managers, audit and logging managers, email and trusted time devices, active directory, etc).

H

6.0.15 The system should have the ability to notify and manage interface based errors. H

6.0.16 The system should have the ability to integrate with leading enterprise management tools such as HP OpenView, Tivoli and LanDesk.

H

7.0 USABILITY REQUIREMENTS

Usability requirements identify what users’ abilities and expectations of usage experiences the product must conform to. Meant to address user friendliness and how the user interfaces (screens) are designed with consideration for the different types or users and their skill sets.

7.1 Ease of Use




7.1.1 The system should provide user friendly GUI controls including but not limited to menus, tree views, text boxes, drop-down lists, list boxes, radio buttons, check boxes, tabs,

H

77




frames and toolbars.

7.1.2 The system should have the ability to allow users to change the font sizing of the system text for their individual preferences.

M

7.1.3 The system should have the ability to provide user-friendly system navigation. H

7.1.4 The system should have the ability to support a minimum screen resolution of 800x600 pixels on notebook, tablet or PC-based devices.

M

7.1.5 The system should employ a robust and comprehensive help system accessible from any point in the system that:

• provides interactive context sensitive help with links to the next step/screen

• provides an index of key terms with hyperlinks to the details

• provides a table of contents with hyperlinks to each section

• is context sensitive based on the field or screen the user's focus is on

• allows for keyword search provides screen overviews / definitions

• can be maintained by non technical users with adequate training and permissions

• provides online tutorials and training materials.

H

7.1.6 The system should have the ability to utilize phonetic search technology when conducting name searches to ensure that similar spellings or sounding text is found.

M

7.1.7 The system should have the ability to provide clear and descriptive error messages. Error messages must be M

78




maintained in a table to allow for ease of maintenance by authorized staff.

7.1.8 The system should have the ability to provide maintenance screens that allow non-technical administrative users to:

• add / modify / delete values in system tables • modify wording on existing error messages • add, delete, or modify wording on document

templates.

M

7.1.9 The system should have the ability to provide an auto save functionality to save users work at set time intervals. M

7.1.10 The system should have the ability to provide functionality to allow a system user to reset their password if a password has been forgotten.

M For example the system should be able to send an email to the user with password reset information.

7.1.11 The system should have the ability to provide a non intrusive password expiry / change reminder. M

7.1.12 The system should have the ability to provide an address normalization capability, which ensures that if the same address is entered several times with variations in the spelling and abbreviations conventions, the variations are standardized and the entries will match.

L

7.1.13 The system should have the ability to provide auto-population and/or verification of postal code based on street or city M Linkage to Canada Post certified software

product will likely be required

7.1.14 The system should have the ability to enable minimized amount of clicking to select and enter information. H For example use of a single click on a

radio check rather than selecting yes/no from a drop down list

7.1.15 The system should have the ability to quickly navigate directly to functionality or documents related to a service or service H

79




recipient.

7.1.16 The system should have the ability to enter data in an assessment, plan, etc. in one screen with scrolling capability, ability to jump to particular sections in the screen and ability to save drafts prior to final save which would check for mandatory fields, etc.

H

7.1.17 The system should have the ability to integrate with voice recognition software, particularly for creating documents and notes.

L

7.1.18 The system should have the ability to print the results of queries, lists and screens. H This would include relationships of service

recipients and other participants and their associated service(s).

7.2 Accessibility




7.2.1 The system should have the ability to extend functionality (e.g., ability to update activity notes, complete risk assessment, etc.) to mobile computing devices (e.g., tablets) and synchronize to a main data store when a secure connection has been re-established. H

Workers should be able to continue to work in the system offline using a device which is not connected to Government’s network. The mobile device should store and synchronize to a main data store when a secure connection has been re-established.

7.2.2 The system should have the ability to link to tools like Map Quest or Google Maps to graphically show physical address L

80




locations.

7.2.3 The system should have the ability to minimize the amount of redundant/duplicate information entered into the system (e.g. enter a data element once and use it in many places). M

7.2.4 The system should have the ability for a user to complete the same function/mass update on multiple records. M

7.2.5 The system should provide the ability for a user to search across multiple functional areas and fields of the application. M

7.2.6 The system should provide the ability for users to search and retrieve data using multiple parameters whether the data is active or closed. H

7.2.7 The system should have the ability to provide a web based access for Government’s extranet partners. M

7.3 Configuration




7.3.1 The system should have the ability to enable authorized non technical users to configure the application to reflect changes in policies, business rules and procedures.

H Business users should not have to depend on technology resources to make configuration changes.

7.3.2 The system should have the ability to validate data inputs (i.e. standardized date formatting, dollar values, etc.). M

81




7.3.3 The system should have the ability to conform to Canadian standards (e.g., Canadian postal codes, Canadian Country Codes, Canadian spell check, etc.).

M

7.3.4 The system should have the ability to support multiple business rules with "if-then-else" level of complexity (e.g., if mandatory fields are not completed then a file cannot be closed).

H

7.3.5 The system should have the ability to enable non technical business users to configure effective dates, status, descriptors and any associated values for individual rules.

M

7.3.6 The system should have the ability to store business rules that have been disabled and superseded by current business rules.

M

7.3.7 The system should have the ability to share business rules across the CYFS application to ensure that rules are only stored once.

M

7.3.8 The system should have the ability to enable non technical users to configure fields that are mandatory, optional and viewable on all system screens.

M

7.3.9 The system should have the ability to configure error and information messages to support data integrity. M

7.3.10 The system should have the ability for non-technical business resources to customize screen presentation views and associated functionality with appropriate permissions.

H

7.3.11 The system should have the ability to provide consistent titling and behaviour of the system from screen to screen. M

82




7.3.12 The system should have the ability to support unique screen titles or screen identifiers to support help-desk functions. M

7.3.13 The system should have the ability for non-technical users to configure terminology that is familiar to the user to label screens and data fields.

M

7.3.14 The system should have the ability to provide the same "look and feel", with some flexibility for personalization by each user throughout the application.

M

7.3.15 The system should have the ability to provide word processing functionality for text fields including cut, copy, paste, spell check, and grammar check.

H

7.3.16 The system should have the ability to provide various help wizards for both system administration and business activities. M

8.0 TRAINING REQUIREMENTS

Training requirements identify all user, help desk and support training required.




8.0.1 The proponent should identify and describe training types, formats, and methods provided for pilot and general rollout. H

8.0.2 The training approach should include consideration for:

• Train-the-trainer approach for end user training; • Description of the skill sets and experiences of the

H

83




individuals that will provide the training; • Individual(s) with previous and in-depth knowledge of

the delivered application who will deliver the training; • Online tutorials and eLearning’s • Detailed scope of the training; • Recommendation on the extent of training required; • Description of training materials / delivery format that

will be provided; • Communication plan; • Change management plan; and • Exclusions to the training.

8.0.3 The proponent should have the ability to provide on-site training for system administrators and support/development staff.

H

8.0.4 The proponent should describe and provide copies of any existing training documentation available. H

8.0.5 The proponent should provide hands on training and documentation to the Infrastructure Services team that includes:

• Server operating system, application component and database maintenance and event handling;

• Updates / upgrades to be applied to the server(s) / application(s) / database(s);

• System rollout support on server (operating system level); and

• Configuration management / change control (operating system, network, application and related software updates).

H

84

9.0 SECURITY REQUIREMENTS

Security requirements identify the security, confidentiality, integrity and privacy issues affecting access to the product, use of the product, and protection of the data the product uses or creates.




9.0.1

The system should comply with security policies defined by the Office of the Chief Information Officer (OCIO) of the Government.

H For additional details on the OCIO security policies, please refer to the OCIO technology binder below.

http://www.ocio.gov.nl.ca/ocio/itresources/EnterpriseArchitectureTechnologyBinder.pdf

9.0.2 The system should have the ability to require the user to enter a username and password to gain access. H

9.0.3 The system should have the ability to configure password rules to enforce a strong password. The system should be able to indicate to the user the specific charters to include or modify to have a strong password.

H

9.0.4 The system should have the ability to utilize 2nd Factor authentication technology. H

9.0.5 The system should have the ability to allow a remote user to securely connect via governments SSL VPN. H

9.0.6 The system should have the ability to give permissions to super-users to create, edit, view and delete users and user groups.

H

9.0.7 The system should have the ability to require user tracking at the application, database and O/S level in order to provide H

85




support for transaction audit.

9.0.8 The system should have the ability to record and track the date and time that interactions are made with the system, the nature of the interaction the user ID having the interaction.

H

9.0.9 The system should have the ability to prevent users from updating records that they are not authorized to update. H

9.0.10

The system should have the ability to flag a service recipient and associated services as highly confidential and severely restrict access to only specified users/roles.

H This requirement particularly pertains to situations where there is a Very Important Person (VIP) involved in a service. VIP could be an employee of the department, a political leader, etc.

9.0.11 The system should have the ability to provide an audit trail, viewable by service providers and printable on demand for the data in the system. The audit trail could include:

• Old value • New value • Time/date of change • User ID of person making the change • Etc.

H

The system should have the ability to display in the service an audit of each time a service is viewed or modified. The audit should display the name date and time of the technical or non-technical person who accessed the service and indicate if the access was to view or modify service information

H

9.0.12 The system should have the ability to automatically time out and require the user to re-authenticate via user ID and H

86




password/PIN when there has been a defined period of inactivity. Any data entered prior to the timeout should be saved and the user should be returned to the point where he/she left off when logging back in.

9.0.13 The system should have the ability to notify users after a configurable period of inactivity prior to system timeout. H

9.0.14 The system should have the ability to allow a system administrator to restrict access to a service recipient’s file based on privileges.

H

9.0.15 The system should have the ability to provide profile and role based access to restrict users to various system functionality defined by the department.

H

9.0.16 The system should have the ability to provide a security model capable of providing additional access restrictions for particular programs or services.

H For example Youth Corrections services are subject to non disclosure and additional system user access restrictions.

9.0.17

The system should have the ability to prevent users from making changes to system-generated data that is determined to be critical.

H Critical data will be defined by CYFS but may include:

• System generated notification • Critical dates • Audit logs

9.0.18 The system should have the ability to support all necessary levels and classes of security to protect system information (such as adoption records, service recipient information and referral sources).

H

9.0.19 The system, where appropriate, should have the ability to leverage data masking technologies to protect critical data stored in the system.

H

87




9.0.20 The system should have the ability to completely delete a system record, including backup of the record and all associated metadata and inform the user that the record has been deleted.

H This requirement is subject to retention requirements as mandated by the IM Assessment completed for the ISM Solution.

9.0.21 The system should have the ability to use industry standard Authentication and Access Mechanisms such as Active Directory and LDAP.

M

9.0.22 The proponent should describe their approach to security maintenance including the approach to security patch updates and upgrades.

H

9.0.23 The proponent should describe their environment strategy for build, test, deployment and testing.

H The ISM system should leverage separate production and training databases where the data in the training DB is masked.

10.0 CLIENT IMPLEMENTATION REQUIREMENTS

Client Implementation requirements identify specific impacts to the client during implementation. Same comments as section 8 training




10.1.1 The proponent should identify the client resource roles (CYFS, OCIO, and other Government Departments) required to implement the new solution including, skills required, estimated effort and approximate timelines for each resource type.

M

10.1.2 The proponent should outline their implementation approach M

88




for the new system.

10.1.3 The proponent should describe the approach to system cutover including the impacts to business continuity during cutover.

M

10.1.4 The proponent should identify the types of support roles, skills and experience required to support the system post go-live. M

10.1.5 The proponent should identify the approach to organizational change management both during the implementation process and post-go live.

M

11.0 DATA CONVERSION AND CLEANSING REQUIREMENTS

Data Conversion requirements identify the specific requirements pertaining to data conversion and cleansing




11.0.1 The proponent should describe their data conversion methodology to move the existing data in the CRMS application to the new solution.

H • Estimated annual new services is approximately 8000

• Estimated active services approximately 20,000

• Estimated inactive services approximately 70,000

11.0.2 The proponent should include the approach to convert both active and closed service recipient information including financial information.

H

89




11.0.3 The proponent should describe their testing and verification approach to ensure consistency and accuracy of the converted and cleansed data.

M

11.0.4 The proponent should describe their approach to converting hardcopy service recipient files to electronic system files for both active and closed service recipient profiles.

M

11.0.6 The data cleansing approach should identity and close service recipient files which should be properly closed.

M

12.0 AVAILABILITY REQUIREMENTS

Availability requirements identify a measurement of the planned uptime during which the system is actually available for use and fully operational. These requirements should be documented in terms of application and required availability.




12.0.1 The system should be available 24x7, 365 days per year. The proponent should describe the recommended system architecture to meet this requirement.

H

13.0 FLEXIBILITY REQUIREMENTS

Flexibility (augmentability and expandability) requirements measure the ease of adding new capabilities to the product.

90




13.0.1 The system should be highly flexible and expandable to accommodate changes in CYFS’ programs, services, policies, legislation and organizational structure.

H

13.0.2 The system should be flexible and configurable to accommodate changes to Government legislation outside the control of CYFS including but not limited to:

• Changes in financial rates (eligibility rates, CWA, taxes, etc.)

• Changes in criminal code impacting sentencing calculations

• Changes in network infrastructure and application security

H

13.0.3 The system should support a service-oriented architecture to allow for future system functionality. H

13.0.4 The system should have a modular or component based design to mitigate as much as possible business interruption when changes are made to the system or new functionality is added.

H

14.0 SYSTEM CAPACITY AND SCALABILITY REQUIREMENTS

System Capacity and Scalability requirements identify the expected load on the system, how many users are likely to access the system concurrently, system usage and the system attributes.




91




14.0.1 The system should have the ability to support approximately 1000 concurrent users.

H

14.0.2 The system should have the ability to manage 25, 000 active services without noticeable impact to system performance.

H

14.0.3 The system should have the ability to capture and manage approximately 9000 new services each year.

H A service includes all activity notes, forms, documents and financial transactions associated with a service recipient.

14.0.4 The system should be designed using n-tiered architecture in alignment with OCIO guidelines and best practices.

H

14.0.5 The system should support load balancing, service redundancy and fail over capabilities.

M

15.0 PERFORMANCE REQUIREMENTS

Performance requirements identify what the application and/or system must do efficiently.




15.0.1 The system should have the ability to update a record in less than 5 seconds.

H A record is any collection of data on a service. For example a record could be a completed risk assessment, or a completed activity note.

15.0.2 The system should have the ability to process system reports without noticeable impacts to operational performance.

H

92




15.0.3 The system should have the ability to complete a primary search on any field in less than 5 seconds

H

15.0.4 The system should have the ability to complete all other searches on any field in less than 1 minute (includes searches using phonetic technology)

H

15.0.5 The system should have the ability to upload and link an electronic document in less than 30 seconds.

H

16.0 ROBUSTNESS REQUIREMENTS

Robustness requirements identify the degree to which the product continues to function properly when confronted with invalid inputs, defects in connected software and hardware components or unexpected operating conditions.




16.0.1 The system should have control measures to validate incorrect data to provide a high degree of data integrity. H

16.0.2

The system should have the ability to limit data loss in the event of a power failure or business interruption.

H

If making updates to the Storage Area Network the system should ensure that all databases are updated at the same time and incomplete transactions rolled back to the point of initiation.

93




16.0.3 The system should have the ability to leverage mobile technology and validate data before it is synchronized with the system’s backend. H

16.04 The system should be able to gracefully manage and minimize system runtime errors. H

Data should be auto recovered and where possible data loss should be prevented in the event of a runtime error.

17.0 INFORMATION MANAGEMENT REQUIREMENTS

The Information Management requirements are meant to ensure that systems have the ability to manage information throughout its lifecycle in compliance with the Management of Information Act and other applicable legislation.




17.0.1 The system should have the ability to track file disclosures including:

• Service Recipient • Disclosure Date • Who the disclosure was made to • Type of disclosure (e.g., ATIPP, Court)

H

17.0.2 The system should have the ability to purge data based on an approved Records Retention and Disposition Schedule with:

• Procedures detailing the process • The capability to delay the disposition process in

the event that data is required for ongoing litigation, ATIPPA request, audits, etc.

H

94




• The capability of producing a disposition report.

17.0.3 The system should have the ability to maintain an Audit trail which captures, at a minimum:

• Additions/modifications to user access rights/permissions

• Any and all action taken on an electronic record or its’ metadata (i.e. search)

• The identity of the user carrying out the action • The date and time of the action • The Audit trail may not be altered • The Audit trail of a record must be retained as long

as the record to which it pertains.

H

17.0.4 Where migration or conversion is required, original data, associated metadata and audit trails (if available) must be retained and preserved. (e.g., refresh snapshot, etc.). H

17.0.5 The system should have the ability to vault all information associated with an adoption service which may include:

• Assignment of a vault number • Restricting access to all users (except authorized

personnel)

H

Vaulting is when a file is frozen in its current state. System users should not be able to change any information which is vaulted.

17.0.6 The system should have the ability to track if a service recipient has given consent to obtain or release personal information with a third party.

H

17.0.7 The system should be able to manage consent at both the service recipient profile level and the service level as it could be possible that the consent may not be given for the complete service information.

H

17.0.8 The system should have the ability to maintain a history of H

95




changes made to data fields. narratives, documents, etc.

17.0.9 The system should have the ability to maintain audit logs across the system infrastructure and across all business, administrators and technical roles. Audit logs should include:

• User ID making the change • Time of the change • Old value • New value

H

17.0.10 The system should send a critical notification to a supervisor or other personnel defined by CYFS when a non authorized user is accessing information they should not be accessing.

H

17.0.11

The system should provide strikethrough functionality for users to change part of a completed text field while maintaining a view of the field that was changed.

H When printing a text field that has a strikethrough, the users should have the ability to select whether or not the strikethrough text is printed.

17.0.11.1 The system should send a notification to a supervisor when certain information is modified or deleted H

17.0.12 The system should have the ability to expunge a record and delete all data and associated metadata if determined appropriate by authorized CYFS users.

H

96

18.0 CATEGORIES OF GROUPS AND EXTERNAL SERVICE PROVIDERS

External providers of service may also receive services from CYFS in the form of application approval, service agreement monitoring, and review. These activities need to be tracked in ISM. However it may be useful for reporting purposes to track activities provided to service recipients and service providers separately.

It is expected CYFS staff would only provide and track financial activities to people defined as “other participants”. Additional information on other participants would only be tracked in the file of the service recipient with whom they are involved.

The external groupings described below are grouped into three types of service provision: residential services, family and child development, and other service providers. A description of the service provided by the external participant and activities performed by CYFS staff for the participant are provided.

RESIDENTIAL SERVICES

Caregiver/Foster Homes and Youth Corrections Community Custody Homes

Foster and Community Custody homes are private family homes that provide residential services to children and youth under the provisions of the Children and Youth Care and Protection Act or the Youth Criminal Justice Act. The homes must go through a formal approval process, participate in orientation and training, and comply with Departmental standards through ongoing monitoring and review.

Activities provided to the homes by CYFS staff include, approvals, monitoring, training and review, as well as investigation of quality of care issues and standards violations.

In Care and Open Custody Group Homes

Group homes provide residential services to children and youth through formal service agreements with CYFS. The services may be provided through the Child and Youth Care and Protection Act or the Youth Criminal Justice Act. The facilities are operated by community boards or corporations.

The role of CYFS staff specific to the homes include administration of service agreements, providing policy development support, training for staff, completing monthly home visits, and participating in program and board meetings.

In Care, Youth Corrections, and Youth Services Individualized/Alternate Living Arrangements (ILA/ALA)

ILAs are long term living arrangements set up for an individual children or youth whose special needs make other placement options unsuitable. ALAs are primarily temporary placements for children when other placements cannot be located. They usually result from a lack of suitable foster home or group home placements. The homes are overseen by a community agency or group.

97

Specific policies are required for the activities provided to these living arrangements and the agencies overseeing them. Activities currently include approvals to set up the placements, financial payments, training for staff, and administration of service agreements.

Other Residential Placements

There are other types of living arrangements for children and youth receiving services from CYFS. The current information system considers these groups only as vendors. Activities provided by staff directly to the residential operators are usually captured in the children or youth’s activity notes. This presents risks when there are concerns about a residential operator as a social worker would only know the concerns if s/he read the file of every child or youth who has lived at the residence.

There is a need for clear policy regarding the type of activities to be provided to operators of these locations. The level of service provided currently varies by program and region. These other placement types include:

• Boarding placements for individuals receiving youth services

• Boarding placements for children and youth with a supervised probation order condition to “to reside at a place that the provincial director may specify”.

• Child Welfare Allowance placements

• Other potential kinship arrangements as defined in the Child and Youth Care and Protection Act

• Out of province treatment facilities (through interprovincial service agreements)

Family and Child Development

Child Care Centers and Family Child Care

Licensed child care services may be centre based or family operated. Centre based services are provided under the direction and management of an operator as defined in the Child Care Services Act. Family based child care services refer to the provision of child care by a licensee, or a person who is supervised by an agency, in the licensee’s or person’s home.

Activities provided by CYFS staff include license approval, monitoring, review of licenses, capacity building, program development and support (including inclusion services) and investigation of alleged legislation and standards violations, or complaints from the public.

Family Child Care Agencies

98

Family Child Care Agencies are community based non-profit, incorporated groups that are licensed by CYFS to approve, support, and monitor family child care homes. Agencies may also provide services to families requiring care such as providing information on quality family care, available child care spaces in agency approved homes and which home’s may best suit a family’s needs.

The role of CYFS with Family Child Care Agencies is to license the agency; monitor standards the agencies sets for approved homes, and annually visit a sample of approved homes under the agency to verify that the service provided to the approved home is adequate.

Family Resource Centers

Family Resource Centers are operated by local groups in a region to provide a variety of community-based activities and resources for children and families that emphasize early childhood development and parenting support. Programs offered reflect the needs of the families who are participating and the communities in which they are located. Examples of family resource programming include Healthy Baby Clubs, parenting workshops, clothing exchanges, and playgroups.

CYFS resources are responsible for administering contribution agreements with the board overseeing the center(s), monitoring, reviewing and approving budgets, reviewing external audit reports, reviewing program and other statistics from the centers, and annual site visits.

Other Service Providers

Extrajudicial Sanctions (EJS) Committees

EJS are formalized programs providing an alternative to judicial proceedings for young persons who are alleged to have committed an eligible offence. The EJS committees are responsible for providing and delivering EJS services. The committees are incorporated and are comprised of community volunteers.

The level of CYFS service provided to the committees varies by region and committee. At a minimum, they are involved in and make recommendations to the Attorney General regarding the initial set-up of committees, attend committee meetings, provide guidance, and ensure compliance with legislation, and provincial policies and standards.

Community Agencies Overseeing Placements and Providing Other Types of Support Services

Throughout the province, community agencies oversee certain types of placements and support services provided to CYFS service recipients. Examples of these types of agencies include Choices for Youth, Waypoints, Daybreak, John Howard Society, and Caregivers Incorporated. At minimum the agencies oversee placements and/or staff working in the placement or with the family. Additional services may be provided depending on the agency. Service agreements are completed between the agency and CYFS detailing the level of service to be provided by the agency and by the Department.

Private Resources

Private individuals may perform a variety of activities to CFYS service recipients. In some cases these services will be provided under the direction or guidance of CYFS. This list of people includes but is not limited to:

99

• Behavioural Aides

• Family Support Workers

• Homemakers

• Counsellors

• Hourly respite staff

• Individuals providing parenting capacity assessments

• Individuals providing psychological assessments

Community Health Partners

The regional health authorities provide numerous services to the children, youth, and families serviced by CYFS including:

• Mental Health and Addictions

• Adolescent Health Counselling Center

• Blomidon Place

• Janeway Child Health Center

Proposed Revised Definitions to Participants in ISM

Service Recipient – An individual or grouping of individuals who receive services from the Department of Child Youth and Family Services.

Service Providers - An external person or group who, through contract or agreement, provides services to service recipients of the Department of Child Youth and Family Services. The service provided may be monitored and tracked by the Department.

Other Participants - Any other individual or group involved in the service or with the service recipient in some way but does note receive a service with the exception of funding from the Department.

Business requirements pertaining to service providers in the ISM Business Requirements Document will instead apply to employees of the Department of Child Youth Services. Requirements pertaining to the above definition of service providers are included in the service recipient section of the document.

100

Based on the above definitions, the CYFS executive identified the participant type for each group as per the following chart:

Participant Type Service Provider

Service Recipient

Other Participants

Foster Homes/Community Custody Homes √

In Care and Open Custody Group Homes √

ILAs and ALAs √

Other Residential Placements (e.g. boarding homes, CWA placements, out of province treatment centres etc.)

√

Child Care Centers and Family Child Care Homes √

Family Child Care Agencies √

Family Resource Centers √

Extrajudicial Sanctions Committees √

101

Participant Type Service Provider

Service Recipient

Other Participants

Community Agencies √

Private Resources

(e.g. Behavioural aids,

parenting capacity assessors, counsellors etc.)

√

Community Health Partners √