CB600 PDF

Fundamentals of the Cúram Enterprise
Framework (V6) for Business Analysts

CB600
An Introduction to Cúram Software
Copyright © 2011 by Cúram Software. All rights reserved. No part of this publication may be reproduced, stored in a
retrieval system, or transmitted by any means; mechanical, photocopying, recording, or otherwise without the written
permission of Cúram Software Disclosure. Use of this publication is prohibited unless permitted by Cúram Software.
Information contained in this publication is subject to change without notice and does not represent a commitment on
behalf of Cúram Software. Although every precaution has been taken in the preparation of this publication, the
publisher and author assume no responsibility for errors or omissions. Neither is any liability assumed for damages
resulting from the use of the information contained herein.
Cúram is a registered trademark of Cúram Software Ltd. All Cúram products and service names are trademarks and
property of Cúram Software Ltd. All Rights Reserved. All third party logos, products, and service names are property of
their respective owners.
Publication date: 27 October, 2011
CB600 Fundamentals of the Cúram Enterprise Framework (V6) for Business Analysts 1
Table of Contents
1. An Introduction to Cúram Software ____________________________________________ 3
2. The Cúram User Interface __________________________________________________ 16
3. Cúram Participant Management _____________________________________________ 29
4. Cúram Case Management __________________________________________________ 46
5. Cúram Temporal Evidence _________________________________________________ 72
6. Cúram Administration _____________________________________________________ 90
7. Cúram Financial Management ______________________________________________ 116
8. Cúram Outcome Management______________________________________________ 136
9. Cúram Case Audit _______________________________________________________ 172
10. Cúram Rules ___________________________________________________________ 193
11. Cúram Workflow ________________________________________________________ 216
12. Cúram Documentation Center ______________________________________________ 229
13. CIARA ________________________________________________________________ 238
14. Cúram Certification Program Overview _______________________________________ 249
15. Getting Ready for Certification _____________________________________________ 258
15.1. Cúram Certification Exams: Registration Instructions _______________________________ 258
15.2. Examination Voucher Usage: Terms and Conditions _______________________________ 268
15.3. Cúram Certified Professional (CCP) V6: Sample Exam Questions _____________________ 269
1. An Introduction to Cúram Software
An Introduction to
Cúram Software
Course Objectives
After completing this course, you will be able to

– describe participant, case, administration, and workflow management
– explain how rules and evidence are defined and used
– describe financial processing and outcome management
– identify Cúram Enterprise Modules
– identify Cúram Business Process Modules
– navigate out-of-the-box Cúram and use its basic functionality
– use the Cúram Documentation Center™
– use the Cúram Impact and Relationship Analyzer™ (CIARA)
Notes:
Lesson Objectives
After completing this lesson, you will be able to

– provide an overview of the following components of the
Cúram Business Application Suite™ (CBAS):
• Cúram Enterprise Framework™
• Cúram Enterprise Modules
• Cúram Business Process Modules
Notes:
Cúram Software
• Founded in 1990
• “Cúram” is Irish Gaelic for “care and protection”
• Headquartered in Dublin, Ireland
• Customers and staff in USA, Canada, Ireland, UK,
Germany, India, Australia, and New Zealand
Cúram Software’s mission is to provide best-in-class, COTS-based

enterprise solutions to social enterprises, including human services,
workforce solutions, and social security. Our solutions promote
improved service delivery of needs-based and contribution-based
programs and allow organizations to focus on client outcomes.
Notes:
Social Enterprise Management (SEM)
Social Enterprises are A business and technology

organizations responsible for Social blueprint that supports the
transformation from a program-
the delivery of essential
services
Enterprise driven business model to a client-
centered, integrated service
Management delivery model
Social Military and

Human
Labor Health Security and Veterans’
Services
Pensions Affairs
UI Benefits TANF Medicaid Income Support Disability

UI Tax Food Stamps WIC Disability Services
Employment Medicaid Mental Health Services Return to Work
Services Child Welfare Adult Services Pensions Workers’
Workers Workers’ Compensation
Child Support EIS
Compensation Compensation
Child Care Disability Loans
Contributions
Services
Loans
Business and Technology

Platform
Notes:
Customers Around the World

BRITISH ALBERTA CALIFORNIA NEVADA INDIANA ONTARIO UNITED GUERNSEY AUSTRALIA
COLUMBIA EII Department of Clark County Family and OACAS KINGDOM Social Disability
WorkSafe BC Service Alberta Social Services Social Services Social MCYS Department Security Services
ACS Services MCTU for Work and Department Queensland
Seniors Administration MCSS Pensions
Legend
UI Benefits
Workforce
Early Intervention Income Support
Services
Juvenile Justice
Workers’ Food Stamps
Social
Security Compensation Income
Support Maternity Benefits & Allowances
Health & Long Term Care
Human Child Care
Services Medicaid Eligibility
Veteran’s Affairs
Medical
Assistance Old Age & Retirement Pensions
Return-to-Work Programs
Appeals Adult Protective Services
Child Welfare
CALIFORNIA UTAH LOUISIANA NORTH NEW ONTARIO NEW GERMANY AUSTRALIA NEW
Department Department Department of CAROLINA YORK WSIB CWC JERSEY City of Department of ZEALAND
of Industrial of Social DSS CITY WSIB Payroll DHS
Hamburg Veterans’ Ministry of
Relations Workforce Services DHHS DOITT Youth and Affairs Social
Services Child Welfare DAAS Social Care Development
DCD
DMA
Notes:
This is only a partial list of Cúram customers.
Cúram Business Application Suite™
Notes:
This diagram is specific to Cúram V6. Other versions of Cúram will have different components.
The three “tiers” of the Cúram Business Application Suite (CBAS) are as follows: Cúram
Enterprise Framework, Cúram Enterprise Modules, Cúram Business Process Modules.
Cúram Enterprise Framework™
The foundational infrastructure and functionality at the

heart of the CBAS
• Case Management
• Business Services
• Technical Services
• Administration Suite
• Application Development Environment
• Documentation Center
Notes:
The Cúram Enterprise Framework is also known by the names “CEF” and “core.”
Case Management: Common Intake, Evidence Management, Participant Management, Eligibility

and Entitlement
Business Services: Task Management, Search, Calendaring/Scheduling, Correspondence
Technical Services: Web Services, Enterprise Application Integration (EAI), Workflow, Security,
Multi-Channel Access
Administration Suite: Online configuration by the system administrator
Application Development Environment (ADE): Coding/development/customization by developers
Documentation Center: Repository of Cúram documentation, including data models and process
flows
Cúram Enterprise Modules
Specialized functionality applicable to many agencies

• Cúram Appeals™
• Cúram BI & Analytics™
• Cúram Citizen Self-Service™
• Cúram Contribution Management™
• Cúram Decision Assist™
• Cúram Evidence Broker™
• Cúram Financial Management™
• Cúram Funded Program Management™
Notes:
Cúram Appeals: Manages the processes around appeals and legal actions.
Cúram BI & Analytics: Data warehousing, embedded analytics, ad-hoc reporting, interactive
dashboards and reports.
Cúram Citizen Self-Service: Enables public access so citizens can screen for programs and apply
online for benefits.
Cúram Contribution Management: Facilitates the collection of taxes and levies for programs, such
as unemployment insurance.
Cúram Decision Assist: Provides agencies with a configurable template for creating structured
questionnaires for caseworkers and social services professionals. Facilitates the creation of
assessments to determine, for example, the severity of a medical condition, or the safety risk to a
child.
Cúram Evidence Broker: Enables flexible data (evidence) sharing between different case types,
as well as between agencies.
Cúram Financial Management: Manages and tracks benefit and liability transactions to assure
complete and accurate financials. Works with the organization‟s financial application.
Cúram Funded Program Management: Enables agencies to create and manage/budget funds,
which can then be obligated to clients in need of assistance.
Cúram Enterprise Modules, continued
• Cúram Intelligent Evidence Gathering™

• Cúram Life Event Management™
• Cúram Outcome Management™
• Cúram Provider Management™
• Cúram Service Planning™
• Cúram Social Enterprise Collaboration™
• Cúram Supervisor Workspace™
• Cúram Verification™
Notes:
Cúram Intelligent Evidence Gathering: Allows for the definition of reusable scripts of questions
using XML-based technology. Guides a user or caseworker though the evidence-collection
process at runtime, asking only questions consistent with previous answers.
Cúram Life Event Management: Enables the caseworker to collect evidence and provide
guidance based on a client‟s life event, such as birth of a child, marriage, divorce, or change in
employment. Works in conjunction with other Enterprise Modules.
Cúram Outcome Management: Uses Outcome Plans to manage assessments, objectives,

activities, and multidisciplinary teams to help a client achieve a specific outcome, rather than
simply deliver benefits.
Cúram Provider Management: Manages the interactions between the agency and its outside
providers, such as foster families, housing facilities, and other vendors.
Cúram Service Planning: A service plan is a mechanism that enables an agency to plan the
delivery of services and activities that help a client to achieve a specific outcome or goal.
Cúram Social Enterprise Collaboration: Facilitates collaboration between agencies and other
interested parties.
Cúram Supervisor Workspace: Enables supervisors to manage the tasks and caseloads of users
assigned to them.
Cúram Verification: Enables organizations to dynamically define and manage the data elements,
as well as the means by which evidence can be verified. For example, the system can inform the
user that they must collect a birth certificate to verify the client‟s date of birth.
Cúram Business Process Modules
Processes and functionality for specific types of

agencies and programs
• Cúram for Income Support™
• Cúram for Medical Assistance™
• Cúram for Child Welfare™
• Cúram for Child Care™
• Cúram for Youth Services™
• Cúram for Workers’ Compensation™
• Cúram for Child Support Enforcement™
Notes:
Cúram business process modules contain pre-built processes, flows, and functionality, including
intake, triage, investigation, evaluation, benefit delivery, and reporting, depending on the specific
module.
Cúram for Income Support: Cash and food programs
Cúram for Medical Assistance: Medical programs
Cúram for Child Welfare: Child protection, child welfare, adoption
Cúram for Child Care: Subsidized child care
Cúram for Youth Services: Youth justice programs
Cúram for Workers‟ Compensation: On-the-job injuries, illness, and rehabilitation
Cúram for Child Support Enforcement: Child support programs
Summary
In this lesson, you have covered the following topics:

– An overview of the following components of the Cúram Business
Application Suite (CBAS):
• Cúram Enterprise Framework
• Cúram Enterprise Modules
• Cúram Business Process Modules
Notes:
The Cúram User Interface
2. The Cúram User Interface
The Cúram
User Interface
Lesson Objectives
After completing this lesson, you will be able to

– identify the three major components of the Cúram user interface
(UI)
– describe the following UI conventions:
• Shortcuts Panel
• Wizards
• Modal Dialogs
• Smart Panel
• Pods
Notes:
Three Major Components of the UI
Application Banner
Application Tabs
Shortcuts Panel
Notes:
The Cúram V6 user interface consists of the following major components:
Application Banner
Application Tabs
Shortcuts Panel
Application Banner
• Application logo • Welcome message

• Application name • Application menu
• User role • Application search
• Application sections
Notes:
Application logo – Customers can change this logo to one that‟s been designed for their project.
Application name – Customers can change the application name.
User role – The role of the user who is currently logged in, for example, Caseworker, Eligibility
Worker, Financial Worker, and Administrator.
Application sections – The application section buttons are located on the bottom left hand corner
of the application banner. There are five application sections:
Home (Mandatory)
Workspace (Mandatory) – The title should reflect the work performed by the user. In this
example, the Workspace tab is called “Cases and Outcomes” because it is being used by a
caseworker.
Inbox (Optional and Pre-Defined)
Calendar (Optional and Pre-Defined)
Reports (Optional)
Welcome message – Located to the left of the application menu. It should be followed by the
name of the user that is logged in. For example, the welcome message should read “Welcome
Paul Murphy.” The user's full name should always be used, not the user's ID.
Application menu – Located on the top-right of the banner. It displays the following menu items:
Preferences, Help, and Log Out.
Application search – The application search is located on the right of the banner. This provides
quick search functionality from anywhere within the application.
Application Tabs
Tab Title Bar
Context Panel
Navigation Bar
Tab Content Page
Page Group Navigation Bar
Notes:
Tab title bar – Contains the tab name and close button, tab title, tab actions menu, and context
panel drop-down toggle.
Context panel – Context panels are displayed directly below the title bar and are an optional
component of the tab. The user can decide to hide or show the panel by clicking the drop-down
toggle button. The context panel presents the user with the most important information regarding
the object. This information gives the user a context, so that when they navigate away from the
home page they still have the relevant information available to them. The context panel can
display a photo of the participant.
Navigation bar – The navigation bar is displayed below the context panel (if present) and contains
the main sub-navigation for the tab. A tab can display just one page or have multiple pages
associated with it. If there are multiple pages associated with the tab, the navigation bar is
displayed. If not, the navigation bar is not displayed. Clicking a navigation bar tab allows the user
to navigate through the tab pages.
Page group navigation bar – When a navigation bar tab represents a group of pages, a page
group navigation bar is displayed on the left side of the page. The page group navigation bar
contains several items, each linking to a page within that group.
Tab content page – Tab content pages are the main information area of the tab. A tab can display
one page or have multiple pages associated with it. Pages contain several components, namely,
Page Title Bar, Clusters, and Lists.
Shortcuts Panel
Expand/Collapse
Notes:
The shortcuts panel is displayed on the left of the interface. It contains links to commonly used
actions and pages and is easily accessible by the user from any page within the section. The
available options are dependant on the user‟s role and security. The panel can be expanded or
contracted. When the panel is contracted, the user can click the arrow at the top of the panel to
expand the panel over the tab. The content of the shortcuts panel is divided into categories.
Clicking the category button highlights the button and moves it to the top of the panel.
Modal Dialogs
Notes:
A modal dialog is launched whenever a user executes an action, for example, New, Edit, and
Delete. In some cases, a modal is launched when a user chooses to view more information about
an item. The modal is displayed in front of the page. This gives the user context. Once the modal
is closed, the user is returned to the page from which the modal was launched.
Wizards
Notes:
Wizards are launched whenever an action or process requires multiple screens for completion.
They contain several linear steps that the user works through in order to complete the task. The
components of the wizard are as follows:
Title Bar
Progress Bar
Content Area
Button Bar
Smart Panel
Notes:
The smart panel is optionally located on the right side of the tab content page. The user can
expand and contract the panel using the arrow on the top-left of the panel. The content of the
smart panel depends on the requirements of the product being implemented. For V6, there are
two components that have been designed for the smart panel, namely, Advisor and Quick Notes.
Advisor – The advisor provides the user with context-aware recommendations and suggestions
for areas that require their attention. It is designed to be a helpful aid that enables the user to
work through the process at hand.
Quick Notes – Quick notes enable the user to take notes while working through the task at hand.
As the user works through pages, quick notes is constantly displayed. This allows the user to
input and save notes at any stage. The user can collapse or expand the smart panel without
affecting the content within.
Home Pages and Pods
Notes:
When the user logs into the application, they are presented with the application home page. This
page consists of several pods that are designed to provide the user with access to their most
important and relevant activities. Most home pages consist of customizable pods. The
administration application is used to define the set of available pods. Users can then choose
which pods they wish to display on screen. Clicking the Customize button in the top-right corner
opens the customize panel. This panel enables the user to decide which pods they want to hide
or show. There are three pods that are common to most applications, namely, Quick Links, My
Appointments, and My Tasks. The user can drag each of the pods to their required position and
can also click the Close button on the pod title bar to hide that specific pod. Clicking the Reset
button in the customize panel returns the home page content to its default display.
Other Icons and Buttons
• Action menus
• Magnifying glass (Search)
• Clear entry
• Calendar
• Refresh
• Help
• Dropdown toggle
Notes:
Action menus – There are three types of action menu in the Cúram interface, namely, tab, pages,
and list. They display the most commonly used actions that apply to the object.
Magnifying glass and clear entry – Some fields in Cúram require you to search for a value to
populate the field, as opposed to typing in a value. Clicking the magnifying glass initiates the
search for a particular value to enter into a field. The Clear Entry icon erases any value that was
placed there. These two icons often appear next to each other.
Calendar – You can manually type a date into a field, or you can click the calendar icon next to
the field in order to select a specific date, which then populates the field.
Refresh – Clicking this button refreshes the content of the page.
Help – Clicking this button opens a context-specific help screen in a new browser window.
Dropdown toggle – These arrows appear at several levels of the UI, including context panel,
cluster, list, and pod. Clicking the arrow allows you to show or hide the content under the specific
object.
Summary

– The three major components of the Cúram user interface (UI)
– The significant UI conventions, including:
• Shortcuts panel
• Wizards
• Modal dialogs
• Smart panel
• Pods
Notes:
Cúram Participant Management
3. Cúram Participant Management
Cúram Participant
Management
Lesson Objectives
• After completing this lesson, you will be able to

– describe Cúram Participant Management
– navigate the Participant Management screens in the Cúram
Business Application Suite™ (CBAS)
– identify and explain Cúram Participant role types
Notes:
What is a Participant?
• A party that has a direct or indirect interaction with

the organization, and about which the organization
needs to record information
• Participant types differ in the way they interact with
the organization
• Each type plays a specific role in the delivery or
receipt of benefits and services
• Cúram enables you to assign multiple participant
role types to a single participant
Notes:
Every organization has individuals or other parties that they need to store information about.
These individuals or parties are categorized into a specific type of role based on the interaction
that they have with the organization. For example, you may have people who claim benefits,
other parties who invoice for services that they provide to the organization, or people who report
important information to the organization. Each of these parties needs to be stored on the system
in the context of the role that they play. In addition, these individuals and other parties may play
more than one role. Using the example above, the person who claims a benefit may also be the
same person who reports important information about another person stored in the system.
Cúram Participant Role Types
Prospect Prospect
Person Employer
Person Employer
Representative Concern Role

External Party
Information
Provider
Educational
Institute
Product Service
Utility
Provider Supplier
Notes:
This diagram focuses on part of the Participant area of the reference model. It contains the
entities needed to manage participants. In the reference model, entities related to participant
management are color-coded yellow. Note that this area of the model is called Concern as shown
above. In Cúram, concern and participant are interchangeable terms.
The Concern Role entity is the key entity in this diagram. The Concern Role entity enables you to
cater for situations where a single participant has several different roles in an organization or
several different interactions with the organization. A concern or participant can be assigned one
or more role types from the types provided by Cúram. For example, as a registered Person, John
Smith, has an active pension (benefit) paid to him. As a registered Employer, he also has an
active unemployment tax (liability) case for his employees. John Smith has two roles because he
has two distinct interactions with the organization. The first role is as a Person in receipt of a
benefit from the organization, whereas the second role is as an Employer paying unemployment
taxes to the organization. You need to complete a separate registration for each participant role
type. However, the participant role types are linked on the system.
Common Participant Elements
• Address • Email address

• Administrator • Financials
• Alternative ID • Interactions
• Attachments • Notes
• Bank Account • Phone Number
• Communications • Roles
• Communication Exceptions • Tasks
• Contacts • Web Addresses
Notes:
These data items and the information that they store apply to all participants irrespective of role
type. In practice, this means that you use some or all of these data items when registering any
type of participant.
Administrator: The user assigned to manage the interactions between the organization and a
participant. For example, Jane Doe, the administrator for the person, Lisa Jones, is responsible
for managing all interactions between the organization and Lisa Jones. The user who registers a
participant is set as that participant's administrator. The administrator can be changed after
registration.
Alternative ID: A form of participant identification. Examples of alternative IDs include passport
numbers and National Insurance numbers. Each participant has a primary alternative ID that is
displayed on all application pages relating to the participant. If an alternative ID is not entered for
a participant at registration, the system automatically generates a reference number that serves
as the participant's alternative ID.
Communications can any of the following: letter, fax, email, or phone call.
Communication Exception: Used to indicate that a participant does not wish to receive (or should
not receive) communications in a specific format.
Interactions: A list of interactions provides information on all of a participant's communications

and payments.
Roles: An individual or entity that interacts with the organization in more than one capacity is
registered as a separate participant type for each capacity. For example, if a registered person is
also registered as an employer, a role record is stored for both the person and employer.
Tasks: A task is an instruction to carry out an item of work. Tasks are usually created
automatically by the system, but they can also be created manually by a user.
Person
• A Person is an individual who has registered with

the organization
• Cúram stores the following Person-specific data:
– Alternative Names – Incidents
– Cases – Insurance Contribution Line
Items and Consolidations
– Citizenships
– Relationships
– Deductions
– Special Cautions
– Education
– Employment
– Foreign Residencies
Notes:
You use the information stored for a person to manage the person's interactions with the
organization. For example, a person's information may be used to determine their eligibility to
receive benefits or services from the organization.
Alternative Name – Any name recorded for a person or prospect person.
Incidents – Events that have, or could have, a direct negative effect on the health and safety of a
person participant, for example, a report of child neglect or abuse, or a work place accident.
Insurance Contribution Line Items and Consolidations – Contributions from, or on behalf of, the
person for purposes, such as unemployment insurance or workers‟ compensation insurance.
Special Cautions – Categories of special cautions include behavioral alerts, for example,
runaway, escapee, and suicide risk; health, such as allergies, contagious disease, and special
dietary needs; and safety issues, for example pertinent criminal history, such as violent or sexual
offender. The list of special cautions can be configured to meet the requirements of the local
organization.
Prospect Person
• A Prospect Person is an individual…

– Who has supplied insufficient information to be registered as a
Person
– The organization does not wish to register as a Person
• A Prospect Person can choose to remain
anonymous
• Use the Prospect Person participant role type to
screen an individual for potential eligibility
• Can be registered later as a Person
participant if required
• Identified in system by a watermark that
reads PROSPECT
Notes:
You can register individuals as Prospect Persons if the organization does not have enough
information to register them as Persons. They are modeled similarly to Persons but there are
fewer information requirements during Prospect Person registration. This means that you can
screen an individual for potential eligibility even if information about that individual is limited. If the
organization gains more information on a prospect after registration, you can then register them
as a Person. Prospect Persons are identified in the system by a watermark in the context pane
indicating the participant is a PROSPECT.
Depending on the agency‟s database policies, Prospect Person data is written to a table and can
be deleted at regular intervals by administrators. For example, administrators can create a
function that deletes all Prospect Person data greater than six months old from the table. The
organization decides how frequently it performs this function.
Merging Duplicate Records
• Information can be merged from a Person record to

another Person record
• Information can also be merged from a Prospect
Person record to a Person record
• A record that has been marked as a duplicate can be
merged immediately or at a later date
• Unmarking a duplicate breaks the links between the
two individuals, but any details selected during the
merge process will need to be manually removed
Notes:
Suppose Linda is registered as a prospect person under her maiden name, “Linda Smith.” Linda
is later registered as a person under her married name, “Linda Williams.” Linda requests that the
organization use her married name when sending correspondence. To facilitate this, Linda
Smith‟s prospect record is merged with the Linda Williams person record.
Merging information for persons and prospect persons consists of three stages, that is, marking a
record as a duplicate of another record, merging information from the duplicate record to the
master record, and completing the merge. Optionally, duplicate records can be unmarked, and a
merge can be quit and resumed. A list of duplicate records is automatically maintained.
Key information such as addresses, phone numbers, and bank accounts can be merged from the
duplicate record to the master record where appropriate. Organizations can configure which key
information can be merged as part of the merge process, via several client-merge, application
property settings.
Employer
• An Employer employs one or more persons,

prospects, or other individuals
• Cúram stores the following Employer-specific data:
– Insurance Contributions
– Related Companies
– Trading Status
Notes:
Employers may also be responsible for submitting insurance returns on behalf of persons in their
employment. In this case, an Employer's information may be used to determine its eligibility to
receive a liability product from the organization. An Employer is also linked to a Person‟s
employment record.
Employer-specific data includes the following:
Insurance Contributions – Employer insurance contributions are recorded as insurance returns.

An insurance return is a record of an employer's contributions on behalf of its employee(s) during
a specified insurance return period.
Related Companies – A related company is a registered employer that is related to another

registered employer. For example, a registered employer may be the parent company of a
subsidiary company that is also a registered employer.
Trading Status – A trading status is a record of whether an employer or prospect employer is

currently trading. An employer or prospect employer's trading status can be actively trading,
ceased trading, or liquidated. Note that only an actively trading employer or prospect employer
can be listed as a person's current employer.
Prospect Employer
• A Prospect Employer is an employer…

– Who has supplied insufficient information to be registered as an
Employer
– The organization does not wish to register as an Employer
• Allows the organization to fully interact with the
employer without the employer being fully registered
on the system
• Can be registered later as an Employer participant if
required
• Identified in system by a watermark
that reads PROSPECT
Notes:
You can register individuals or companies as Prospect Employers if the organization does not
have enough information to register them as Employers. If the organization gains more
information on a Prospect Employer after registration, you can then register them as an
Employer. This Register an Employer from a Prospect Employer functionality is located as an
option on the Prospect Employer home page.
Prospect Employers are identified in the system by a watermark in the context pane indicating the
participant is a PROSPECT.
Product Provider
• Product Providers offer products to persons or

employers on behalf of the organization
• A product is either a benefit or liability issued to a
participant
• Cúram stores the following Product Provider-
specific data:
– Products
– Locations
Notes:
Examples of products may include disability allowance, sickness benefit, and income support. For
example, the organization may form a contract with an outside Product Provider so that it can
offer child care to eligible persons. In this case, the organization assesses eligibility for the
product, but it is actually delivered to its customers by an external Product Provider. However, the
organization itself may be a Product Provider.
Representative
• A Representative is an individual who interacts with

the organization on behalf of another participant
• Representatives can be contacts for participants,
correspondents for participants or cases, or
nominees who receive benefits on behalf of persons
Notes:
Representatives are registered as part of creating other roles, rather than as an independent
business process. These other roles are contacts for participants, correspondents for participants
or cases, and case nominees. For example, when a letter is sent to a correspondent who is not
already a registered participant, the correspondent is automatically registered as a
Representative.
Note – You generally access Representative records from the area of the application where they
were registered. This is because their purpose only relates to the other role for which they were
added.
There is no home page in Cúram for Representatives, as they are always associated with other
participant types or cases.
Other Participant Types
• Service Supplier
– Offers services to individuals on behalf of the organization
• Information Provider
– Supplies the organization with information about other participants
• Utility
– Provides essential commodities, such as electricity, gas, or water
• Educational Institute
– Provides educational services to participants
• External Party
– Interacts with the agency on behalf of another participant
Notes:
Service Supplier
Offers services to individuals on behalf of the organization. A service is performed by a qualified
individual or organization. The Service Supplier role allows the organization to outsource services
that it does not perform. Cúram stores the following Service Supplier-specific data: Returns
(invoices) and Services. Examples of a service include eye examinations and court translations.
For example, an organization may cover the cost of an elderly person's regular eye examinations.
The organization may contract specific services to an external supplier that are required for
assessing benefit eligibility. For example, an organization may refer a customer to a doctor for
regular medical examinations. The result of the examination may determine ongoing eligibility for
a sickness benefit.
Information Provider
Information Providers supply the organization with information relevant to other participants. This
information is generally used in the prevention of fraud. Information Providers can include private
individuals, government agencies, and registered data brokers. Cúram stores limited details
about Information Providers because they play a peripheral role and do not directly deliver or
receive products or services. When registering an Information Provider, you can check whether it
is already registered as a person. Once you are satisfied that the Information Provider does not
already exist, you can record registration details. These details include personal details, contact
details, and demographic information. An example of an Information Provider would be an
individual who reports alleged fraud against a benefit product recipient.
Utility
An external organization paid by the Human Services organization on behalf of a participant for
such essential commodities as electricity, gas, or water. Organizational interaction with utilities
typically involves the issuance of payments based on deductions taken from a person‟s benefit
payments. Utility transactions are handled by case and financial processing. Suppose that John
Smith receives a monthly benefit payment of $100 from the organization. He can elect to deduct
part of this benefit to make electricity payments, in this case $20. So the organization issues a
monthly payment of $20 to the electricity supplier based on the agreed deduction.
Educational Institute
Educational Institutes provide educational services to participants. Examples of Educational
Institutes include elementary schools, junior schools, open universities, and vocational training
institutes. Educational institute registration information differs from the standard registration
information recorded for other participants. In addition to standard information, such as
preferences and contact details, the educational institute type is also recorded. Educational
institute registration information also indicates whether the educational institute is a public or
private organization.
External Party
An individual or organization that interacts with the agency on behalf of another participant, for
example, community-based organization (CBO). An External Party can submit an application and
supporting materials on behalf of another participant. Cúram stores the following External Party-
specific data: Office and Office Member. Often the agency needs to be able to interact with
external parties, and external parties need to be able to access the agency‟s system to carry out
various functions. Potentially, there will be many types of external party interacting with the
agency. They can log on to the agency‟s application through an external portal and view
information specific to them. They can manage their own users, and each user can carry out
certain functions, for example, verifications. An office is a location where the external party carries
out its services. The individuals associated with an external party office (office members) can
become external users of the system.
Searching for Participants
• Common search criteria for participants includes:

– Reference number
– Name
– Address
• Specific search criteria is provided for certain
participants:
– Example: Date of birth for person participants
• For person searches, the user can utilize nickname
and phonetic searching
• Wildcard % character can be used to refine searches
• A quick search can be accessed from anywhere in
the application
Notes:
Common search criteria for participants include a reference number for any alternate
identification; name, which includes any alternate name for the participant; and address. In
addition, specific search criteria are provided for certain participants, for example, date of birth for
person participants.
For person participant searches, the user can use nickname and phonetic searching. If a
nickname search is performed, the search will return a list of all persons and prospect persons
registered under the nickname and the name associated with the nickname. For example, a
person registered as "James" may also go by the name "Jimmy". If a nickname search is
performed and the name "Jimmy" is specified in the search criteria, the system will return a list of
all persons registered as either "Jimmy" or "James".
Phonetic, or sounds like, searching is implemented as standard in respect of a person‟s last

name. Phonetic searches return similar sounding names. For example, a search for ”Smith” will
also return ”Smyth”, ”Smythe”, and any other similar sounding names.
When searching, the wildcard character “%” can be substituted for zero or more characters. For
example, to search for test, tests, or tester, you can use the search, “test%”.
Cúram provides a quick search facility. The quick search can be accessed from anywhere in the
application. It allows a user to enter a reference number and search across all cases,
participants, investigations, and incidents.
Summary
• In this lesson, you have covered the following topics:

– The Cúram participant (or concern) role types
– Management of common and exclusive data for these role types
Notes:
Cúram Case Management
4. Cúram Case Management
Cúram Case
Management
Lesson Objectives

– discuss how cases are used in Cúram
– identify the case types in the Cúram Enterprise Framework™
and their respective purposes
– describe the processing that is involved in delivering a benefit via
a product delivery case
Notes:
What is a Case?
• In Cúram, a case is an interaction between a

participant and the organization
• You use cases to manage the interactions that a
participant has with the organization
Notes:
A typical case contains information about the participants wishing to receive a benefit or service,
information about other participants involved in the case, evidence used to make the
determination, eligibility decision information, and a record of all financial transactions made on
that case. It also contains information about communications between the organization and
participants, any notes recorded for the case, and events that occurred as part of case
processing. Essentially, the case becomes a folder for all the information needed to manage the
participants and the benefits or services they receive from the organization.
For example, if a person makes a claim for an unemployment benefit, a case is created to
manage this claim. This triggers a sequential chain of events that includes gathering evidence
about the person's job loss, determining whether the person is eligible for benefits, and delivering
the benefits accordingly. The series of stages or events that the case passes through during its
lifetime is called the case life cycle.
Cúram Case Types
• There are six case types in the Cúram Enterprise

Framework™
– Screening
– Assessment
– Integrated
– Product Delivery
– Issue
– Investigation
• Each case type has a different purpose in the
delivery of the organization's benefits and services
• Case types can differ by when and where they are
used
Notes:
The screening case type consolidates one or more assessments for one or more members of the
same household. The assessment case type performs an initial evaluation to determine whether
a person or prospect person is potentially eligible for an individual program or service. The
integrated case type is used as a master container for all other case types for a given client or
household. The product delivery case type determines actual eligibility and entitlement to benefits
and delivers those benefits. The issue case type is used to capture and manage differences in
evidence or information received by a claimant and a third party. The investigation case type is
used to manage the investigation of an incident or allegation.
Case types differ by when and where they are used in the case life cycle. For example, you use
an assessment case to determine a claimant‟s potential eligibility. You can then store one or
more assessments in a screening case to further assess potential eligibility. You can then transfer
the results of this eligibility processing to one or more product delivery cases. You can then
manage these interconnected product delivery, screening, and assessment cases via a single
integrated case. The functional differences between Cúram case types map to when and where
you use them.
Screening Case
• You use a screening case to handle and store

several program-specific assessment cases
• One of the advantages of a screening case is that
evidence for multiple assessments can be entered at
the screening case level
• This allows the organization to get an immediate
evaluation of a client's potential eligibility for
multiple programs
Notes:
Assessment Case
• You use an assessment case to perform an initial

evaluation to determine whether a person or
prospect is potentially eligible for a benefit or
service
• It enables the organization to determine potential
eligibility for an individual program without creating
a product delivery case
• Each assessment case represents a
program/product
• Each assessment case has a rule set assigned to it
Notes:
Integrated Case
• The purpose of the integrated case is to consolidate

case information for one or more participants
• You can use an integrated case as a folder to store
and manage multiple cases (of any type) for one or
more members of the same household or family
• The integrated case life cycle consists of only two
stages:
– Open
– Closed
Notes:
An integrated case type is similar to a screening case type in that both act as containers for
consolidating information. Like screening cases, evidence can be maintained at the integrated
case level and shared among the cases contained within the integrated case.
When you create an integrated case, the integrated case has a status of Open. Note that each
case within the integrated case has its own life cycle.
Product Delivery Case
• A product delivery case determines whether a

participant meets the actual eligibility criteria for a
single benefit or liability product
• It also contains the functions needed to manage the
delivery of these benefits or liabilities
• An eligibility determination usually results in the
benefit being delivered in the form of a payment, or a
bill for a liability
• Each product delivery case has a rule set assigned
to it
Notes:
Benefits are usually delivered to persons in the form of ongoing monetary payments. For
example, a person may receive weekly or monthly payments as part of their unemployment
benefit entitlement.
Alternatively, liabilities are delivered to persons or employers in the form of a bill. For example, a
person may be billed for an overpaid benefit, or an employer may be billed for contributions to the
workers‟ compensation fund. Like assessment case types, each product delivery case has a rule
set assigned to it. The difference is that rule sets assigned to product deliveries are used to
determine actual eligibility. Rule sets that are assigned to assessments are used to determine
potential eligibility.
Issue Case
• The Issue case type is used to capture and manage

differences in evidence or information received from
a participant and a third party
– For example, if the reason given by a client for leaving a job is
different from the reason provided by their employer, the
organization may wish to investigate this further
• The Issue case type contains several processes to
help track and resolve these discrepancies
– Issue Types
– Issue Resolution
– Issue Resolution Approval Checks
Notes:
When a customer applies for assistance or advises changes of circumstances during ongoing
case maintenance, they supply information to help the organization determine or reassess their
eligibility. For some types of information, the organization is likely to verify accuracy with a third
party. For example, John Smith has left his job and is applying for an unemployment benefit. He
completes an application form and when asked for Reason for Leaving Employment, John enters
that he was laid off. This information is captured in the system and, at the same time, the
caseworker overseeing John‟s case sends a notice to the employer to verify last pay details and
cessation. When the caseworker receives the form back from the employer, she notices that John
was actually fired on the grounds of severe misconduct. As it turns out, John disagrees with the
firing and is taking action with an employment lawyer to challenge his employer for wrongful
dismissal. The reason for leaving employment will have an impact on John‟s eligibility for an
unemployment benefit.
In this scenario, there is a discrepancy between the information provided by John and the
information provided by the employer. As John is taking legal action against his former employer,
it is not necessarily a straightforward case. Cúram issue cases allow organizations to manage
these scenarios within a case.
Investigation Case
• Used to investigate allegations and incidents
– Benefit fraud
– Child abuse
– Criminal activity
• Features and functionality

– Allegations
– Findings (founded, unfounded)
– Resolutions
– Action Plans
– Milestones
– Contact Logs
– Translation
– History
Notes:
Investigation cases are used to inquire into circumstances surrounding an allegation or incident.
Organizations receive thousands of reports each year that must be investigated. Examples of
types of allegation that require investigation include child maltreatment or benefit fraud.
Investigation cases allow organizations to record all relevant details concerning any type of
investigation. All information surrounding the allegation is recorded, including interviews,
assessments, notes, and communications sent or received. These provide the organization with
the relevant details to complete the findings, record a decision on the investigation, and resolve
the allegation or incident.
Case User Roles

1. Case owner
– Responsible for case information and maintenance
– Case owner can be any of the following:
1. User
2. Position
3. Organization Unit
4. Work Queue
2. Case supervisor
– Responsible for reviewing or approving cases submitted for
approval
3. Case reviewer
– Responsible for carrying out periodic review of product delivery
cases
Notes:
When you create a case, Cúram automatically assigns a case owner. The default case owner for
all case types, apart from issues, is the same user who registered the first participant added to
the case, namely, the primary case participant. A case may also be owned by a position, an
organization unit, or a work queue. If ownership is assigned to any of these organizational
objects, any user assigned to that entity will have ownership rights to the case.
An administrator can associate a case type with a case-ownership strategy process. When a
case is being created, if a case-ownership strategy workflow process has been associated to the
case type, the initial case owner is determined using the workflow process. If not, the sample,
out-of-the-box algorithm will be used.
Along with a case owner, a Supervisor role can also be assigned to a case manually or
automatically. The purpose of assigning a supervisor role is so that they can take action on
approval requests for the case. Automatic assignment of a supervisor is determined by the
reporting hierarchy in the organization structure, which is set up in the Cúram Administration
Manager. Note that a supervisor is dynamically assigned only when an action that requires the
intervention of a supervisor on a task, or notification is performed on the case.
The case reviewer role is responsible for performing periodic reviews on a Product Delivery case.
Case reviews can be set manually as a case event, or scheduled at a regular frequency, as
determined by a setting in product administration. By default, the case reviewer will be the same
as the case owner.
Cúram Case Elements
• You will see the following sections and information in

Cúram cases:
 Home – Case Details (Case Header Entity), Recent Transactions
 Participants
 Contact – Notes, Attachments, Meeting Minutes,
Communications
 Events (Calendar) – Meeting, Reviews, Referrals, Activities
 Tasks
 Issues and Proceedings – Investigation, Issue Cases
 Administration – Related Cases, Transaction History, and User
Roles
Notes:
Case Details
Case Details display summary details about a case. For example, creation or start dates,
objectives, the current status of the case, etc. CaseHeader is the name of the data model entity
(database table) that stores high-level information about a case.
Participants
Case Participants represent all of the different participant types who play a role in the case. For
example, you will usually have a Person participant who has a role of Primary case participant.
Other household members in the application group will have a role of Case Member. Each
participant may play more than one role in the case.
Contact
The Contact tab may contain the details of user-entered notes, attachments, records of meeting
minutes, and records of communications.
Events
An event is an individual milestone of significance to a case. Events can be automatically created
by the system as a result of case processing, or manually created by a user. An example of an
event created by the system is the case closure event. The following events can be created
manually: meetings, reviews, referrals, and activities. All of these items can be displayed in either
a list or a calendar view.
Tasks
A task is an instruction to carry out an item of work. Tasks are either manually created by a user
or automatically created by the system. Tasks that relate to a case can be maintained from the
case task list.
Issues and Proceedings

Issues and legal proceedings can include issue cases with evidence, investigation cases into
allegations, appeal cases of cases or determinations, legal actions by courts, and special
cautions/warnings about participants.
Administration
The Administration tab provides links to information on related cases, transaction history, and
user roles for the case.
Cúram Case Elements, continued
• Integrated Case specific elements:

– Assessments
– Outcome Plans
• Product Delivery Case specific elements:

– Determinations: Current, History
– Financials: Transactions, Certifications, Deductions,
Components, Delivery Patterns, Nominees, Over and Under
Payments, Payment Simulations
Notes:
Assessments – Assessments can be run for one or multiple family members from within an
integrated case in order to identify their strengths and needs and/or barriers.
Outcome Plans – Outcome Plans are used to manage the provision of activities to address the
client‟s particular circumstances in order to achieve a specific goal, such as self-sufficiency, or
return to the family.
Determinations – Within a Determination are one or more decisions, each one defining the
client‟s eligibility and entitlement for one or more components within a product.
Financials
Transactions are the payments and bills issued for eligible and active product delivery
cases.
Certifications are the eligibility periods for the products.
Deductions are money subtracted from benefit payments.
Components represent the various categories of payment for a product.
Delivery Patterns consist of the delivery method (cash, EFT) and delivery frequency
(weekly, monthly) of benefit payments.
Nominees are the recipients of benefit payments.
Over and Under Payments: An overpayment occurs when too much has been paid out on
the case. An underpayment occurs when too little has been paid out on the case.
Payment Simulations: Payment simulation allows a caseworker to see all payments and
deductions due to a participant for a specific date before the payment is issued.
Delivering Benefits through Product Deliveries
1. Create Integrated Case

2. Enter and Activate Evidence
3. Create Product Delivery Case
4. Check Eligibility
5. Submit for Approval
6. Activate Case
7. Issue Payment
Notes:
To take advantage of integrated case functionality, product delivery cases are created within an
integrated case by default. Typically, the case owner enters evidence and checks eligibility before
submitting the case for approval. Ineligible cases cannot be activated. Evidence sets are
maintained by a caseworker. All evidence sets are assigned a status of In Edit, Active,
Superseded, or Canceled. The most important status is active because benefit payments can
only be issued on an active evidence set. A case owner can also check eligibility for evidence
with a status of In Edit. If the decision returned is the desired outcome, the owner can choose to
activate the evidence and submit the product delivery case for approval. Once the case is
approved, it is ready to be activated by either the running of the rule set, or manually by the case
owner.
Product Delivery Case Life Cycle
• Life cycle • Statuses

– Case Creation – Open
– Case Approval – Submitted
– Case Activation – Approved
– Case Suspension – Active
– Case Closure – Suspended
– Case Reactivation – Pending Closure
– Closed
– Delayed Process
Pending
Notes:
Each stage in the life cycle is assigned a case status. For example, when you first create a
product delivery case, its status is open. If a case is in between case processes, the status is
delayed process pending. The case status indicates the current stage in the case life cycle. It also
dictates the stage or stages a case can progress to next. For example, you must approve an
open case before you can activate it.
A case status history is maintained for a product delivery case throughout its life cycle.
Product Delivery Case Nominees
• A nominee is a case participant who receives

payments or bills from the organization
• A nominee is assigned to a case component, which
is usually a financial objective in product delivery
cases
• A case can have multiple components, and you can
assign more than one component to a nominee
• A case can have multiple nominees
• The default case nominee for all case components is
the primary client
Notes:
Case components for product delivery cases are units of entitlement, typically financial units of
entitlement, that are available with a benefit. For example, personal component, child dependent,
and spousal dependent are units of financial entitlement with a benefit case. As there can be
multiple case components, a component assignment history is maintained for each case
component. This tracks the nominees assigned to one component over time. Although the
primary client is the default nominee, a case participant other than the primary client can be
nominated to receive benefits for a case component. For example, a person's employer can be
nominated to receive a person's benefits.
Nominee delivery patterns are used to create financial schedules for each case component. A
nominee may have the same or a different delivery pattern for each of the components.
Product Delivery Case Suspension
• You can suspend an active product delivery case

• Suspending the case prevents future payments from
being issued until the case is unsuspended
• Unsuspending a suspended case changes the status
back to open
– Future payments are issued only after the case is approved and
activated again
Notes:
When a case is suspended, new payments cannot be created until the case is unsuspended.
When you unsuspend a case, the status of the unsuspended case returns to Open, and the
caseworker must progress the case back to Active status in order to resume payment.
Product Delivery Case Closure
• A case can be closed automatically by the system

when its certification period expires, or if it is found
to be ineligible
• You can also close a case manually at any point in
its life cycle, or configure it to close on a specific
future date
• When you set a case to close on a date in the future,
the status is set to pending closure
– It remains in this status until the closure date, at which time it
changes to closed
Notes:
When you close a case, all associated information and events, such as case reviews and case
referrals, are closed. In addition, a case communication is generated for the primary client. A
case communication is a correspondence to or from the organization that is created within a
case. You can create additional case closure communications for other case participants, such as
a service supplier, on a case referral.
Product Delivery Case Reactivation
• You can reactivate cases with a status of closed or

pending closure
• The status of the reactivated case is open
– To deliver benefits on the case, it must go through the approval
and activation stages again
Notes:
Cases with a status of Closed or Pending Closure can be reactivated. For example, a person's
benefits may be discontinued once the person is in regular employment. If that person is laid off
from the new employer and is once again eligible for benefits, the existing product delivery case
can be reactivated.
Product Delivery Case Reassessment
• Case reassessment reevaluates payments or bills

when there is a change in circumstance (evidence)
on a product delivery case
• The system compares the existing set of decisions
for a given period with a new set generated by
evidence changes
– If the decision sets are unequal, reassessment compares what
was paid or billed and calculates an overpayment or
underpayment amount
• A correction case, overpayment case, or
underpayment case can be created, linking it to the
product delivery case that triggered the over or
underpayment
Notes:
Case reassessment is performed automatically at different points of the product delivery case life
cycle. Before any payment is authorized on a case, reassessment occurs automatically to
determine whether there has been any change in evidence or certification. Certification validates
evidence over a set time period. Reassessment also occurs automatically when a case is closed.
A user may also manually initiate reassessment of a product delivery case at any time.
Product Delivery Case Administration
• There are two types of Product Delivery case:

– Benefit
– Liability
• Product administration includes the maintenance of
benefit and liability products, as well as the delivery
methods for these products
• Certain information can be maintained for both
product types
• Other information is benefit or liability-specific
Notes:
Benefit – Money or services are being distributed from the agency to the client.
Liability – Money is being collected from the client.
Information Common to Benefits and Liabilities
• Home: Details, Processing, Participants, Security

• Approval Checks: Cases and Evidence
• Evidence Types
• Financial: Patterns, Provisions
• Ongoing Case Management: Time Constraints,
Absence Reasons
• Rule Sets
Notes:
Home
Details: General case information, including start dates and status.
Processing: Includes information about adjustments, over/under payment processing, and
certification.
Participants: Details which participant types may receive the benefit.
Security: Lists the security identifiers required to work with the product.
Approval Checks
Case: Percentage and dollar amount thresholds.
Evidence: Type and percentage thresholds.
Evidence Types
The detailed listing of evidence records used by the product to determine eligibility.
Financial
Patterns: Describes delivery methods (EFT, cash) and delivery frequencies (weekly, monthly)
available for use.
Provision: Lists the product providers that can provide the benefit.
Ongoing Case Management

Time Constraints: Time limits applied to certain aspects of product processing.
Absence Reasons: Absence reasons are used to define the acceptable absence reasons
applicable to a particular program, such as Food Stamps. For example, an absence Reason of
'family bereavement' may be an acceptable reason for a client to be absent from a scheduled on-
the-job training activity they are required to attend for one program, but not for another.
Rule Sets
The rule set the product will use to determine eligibility and entitlement.
Case Administration
• Integrated cases
– Evidence, Assessments, Milestones
• Product Delivery cases
– Benefits, Liabilities, Case Reassessment Requests
• Screening cases
– Assessment, Milestones
• Assessment cases
– Benefit Products, Integrated Cases, Rule Sets
• Issue cases
– Appeals, Resolutions, Resolution Approvals, Time Constraints
• Investigation cases
– Assessments, Approval Checks, Milestones, Resolutions
Notes:
Here are some of the key items that require configuration by a system administrator in order for
front-line users (caseworkers) to be able to use these types of case.
Summary

– The six case types in the Cúram Enterprise Framework and how
they are used
– The life cycle of a product delivery case and the steps required to
deliver a benefit with this case
– The administration set-up requirements for each case type
Notes:
Cúram Temporal Evidence
5. Cúram Temporal Evidence
Cúram Temporal
Evidence
Lesson Objectives

– describe the functionality of Cúram Temporal Evidence
– define key pieces of temporal evidence terminology
– list and describe the temporal evidence maintenance functions
provided by the Cúram Temporal Evidence framework
Notes:
What is Cúram Temporal Evidence?
• Evidence is the data captured about clients to

determine their eligibility for benefits and services
• The Rules Engine runs the rules against the
evidence and produces a decision, for example,
eligible, ineligible, or amount
• Each piece of evidence is a discrete unit of
information that can change over time
Notes:
Cúram Temporal Evidence was introduced in Cúram V4.5. Prior to this version, evidence was
stored in an evidence tree format. Temporal evidence allows for a more granular approach to
evidence collection and maintenance. With evidence trees, an entire set of evidence was
assigned effective dates. By contrast, temporal evidence allows each individual evidence record
to have its own effective date.
Evidence Types
• Evidence types represent the events and

circumstances that must be captured for case
assessment purposes
– Examples: Income, expenses, assets, household
• An evidence object consists of one or more evidence
records
• An evidence record is a set of saved information
entered for an evidence type
Notes:
The circumstances of a case participant determine the number of evidence records in a given
evidence workspace. For example, if a Participant has two jobs, two different evidence objects
are stored within the employment evidence type to record all necessary information. In addition,
evidence records are added to reflect changes in circumstances. For example, if the details of
one of the jobs changes, a new evidence record is added to correct the outdated record.
Case and Participant Evidence
• Evidence records must be associated with a case

– Evidence associated with an Integrated Case can be used by the
Product Delivery Cases within the Integrated Case
• Evidence records must be associated with a
participant
– Certain evidence captured during registration, for example, date
of birth, can be used by any case in which the person is a case
member
• “Record once. Use multiple times.”
Notes:
Each evidence record is associated with a case. Evidence records associated with an integrated
case can be shared across multiple product delivery cases within that integrated case. This is
useful because products often have common information requirements. For example, several
products may require income evidence. The system administrator associates evidence types with
case types in the Product section of the Cúram administration manager.
Evidence from Participant Manager
• Evidence entered and maintained in the Person

Home Page, as opposed to the Case Manager
– Date of birth
– Alternate name
– Alternate ID
– Citizenship
– Education
– Employment
• History/Snapshot
Notes:
Participant evidence is evidence that is captured in the participant manager. A history of evidence
changes is kept. This history is typically known as snapshot entities in the reference model.
When a piece of participant evidence is modified in the Participant Manager, prior to any
modifications being applied, a snapshot of the participant evidence record is created. Once
changes are applied to the record, the original evidence record will be superseded by the new in-
edit version. Modifications to participant evidence will require approval if approval has been
configured for the evidence type.
Evidence Edits – Two Types
• Evidence Correction
• Change in Circumstance
Notes:
An evidence correction is the replacement of an existing evidence record with a new evidence
record in order to correct an incorrect piece of data, such as correcting a bank account number,
or date.
Data in an evidence record changes over time due to a life change, such as losing a job, getting a
new job, or having a child. These types of evidence change are often called “changes in
circumstance.”
Time Slices
Time Event
Dependant Dependant
Evidence Evidence
•---- •----
•----
New child
•----
•---- •----
Postal Postal
Address Address
•---- •----
Move
•---- •----
•---- •----
house
Income Income
Evidence Evidence
•---- •----
Lose job
•---- •----
•---- •----
Personal
Details
•----
Get older
•----
•----
Notes:
In this example, the benefit product uses the following evidence types: dependants, address,
income, and age. This kind of evidence-change history typically applies to products paid on a
recurring basis. Events that change circumstances trigger changes to evidence. Examples of
these events include a new child (changes dependant evidence); moving to a new house
(changes address evidence); loss of a job (changes income evidence); or the passage of time
(products can have age cut-off points). Changes to evidence divide the case life cycle into a
series of time-slices. The effective date of each piece of evidence gives a time-slice date, that is,
the date on which a decision might change.
Time slices create two major evidence maintenance requirements. We need to capture and
accurately assess old cases where the claim is made after the event that led to the claim. We
also need to reassess historical cases where evidence used at the time is subsequently found to
be incorrect due to error or fraud. On any given date, each piece of evidence is either effective or
ineffective. Consequently, each piece of evidence has an effective date range. Temporal
evidence addresses these requirements by storing each piece of evidence separately rather than
in a single tree that contains multiple pieces of evidence. So each piece of evidence can have its
own effective period.
Attribution Periods
• Period during which an evidence record is active and

being used for assessment, in other words, when the
system applies the evidence to the case
• The calculation of the attribution period is a key
feature of the Cúram Temporal Evidence framework
• With Cúram Temporal Evidence, the system, not the
caseworker, calculates the attribution period
Notes:
The user enters the required evidence effective dates, such as a start and end date, and
activates the evidence. The system calculates attribution periods for the active evidence record
based on these dates and the requirements of any product deliveries that share the evidence.
More than one attribution period will be created for evidence that is shared across multiple
products. For example, an integrated case may have employment evidence that is shared across
three product delivery cases. An attribution period is calculated for each product delivery case
based on its individual rules. This means that the same evidence record can be used for
assessment on all three cases.
The attribution period may or may not coincide with the evidence start and end dates. Based on
the rules and requirements of the specific product, the system (rather than the user) will calculate
the attribution period.
Evidence Workspaces
• Evidence Dashboard
• Evidence Flow
• Active Evidence
• In Edit Evidence
• Verifications
• Issues
• Incoming Evidence
Notes:
Evidence Dashboard
The dashboard provides a summary view of evidence for a case.
Evidence Flow
Evidence Flow is a tool that allows caseworkers to quickly navigate through evidence.
Active Evidence
The active evidence list provides caseworkers with a view of all active evidence on a case. From
this list, active evidence records can be viewed, updated, and deleted. Additionally, pending
updates set on active records can be discarded, and pending removals set on active evidence
records can be undone.
In Edit Evidence
The In-Edit Evidence List provides caseworkers with a view of all the in edit evidence on a case.
From this list, in edit evidence records can be viewed, edited, and discarded. By default, the in
edit evidence list displays all of a case's in edit evidence records, including parent and child
evidence.
Verifications
Verifications require the provision of a document or action in order to verify the accuracy of the
data captured. Verifications are configured in the administration manager. The Verifications List
displays all of the verifications, both outstanding and completed, that are currently associated with
the case evidence. Users can also manage verification requirements from the list. Note that
evidence can only be shared if the Cúram Verifications Enterprise Module is installed.
Issues
Issues highlight missing information that is required before eligibility can be determined. The
Issues List displays all of the issues associated with the evidence on a case. Caseworkers can
use this list to resolve issues. The evidence issues are determined by the Smart Panel/Advisor
rules.
Incoming Evidence
The Incoming Evidence list provides caseworkers with a list of evidence that has been shared
(broadcasted) from other systems or areas to this case. Evidence from different sources can be
compared to existing evidence on the case, allowing caseworkers to make an informed decision
about whether accept it. Note that evidence can only be shared if the Cúram Evidence Broker
Enterprise Module is installed.
Evidence Dashboard (Categories and Icons)
Notes:
The dashboard provides a summary view of evidence for a case. It groups evidence by category,
for example, household, income, assets, and expenses. It also groups evidence by the following
views:
Views
All – All evidence types that have been configured for that category on a case.
Recorded – All evidence that has been recorded for that category on a case.
Not Recorded – All evidence that has not been recorded for that category on a case.
Icons
Issue – Issues highlight missing information that is required before eligibility can be determined.
Items to Verify – Items to verify highlight evidence that require the provision of a document or
action in order to verify accuracy of the data captured. Verifications can be configured in the
administration suite when the Cúram Verifications Enterprise Module is included in the build.
Evidence in Edit – Highlights evidence that is not yet applied and, therefore, not yet activated and
ready to be used for eligibility determination.
Evidence Flow
Notes:
Evidence Flow is a tool that allows caseworkers to quickly navigate through evidence.
Evidence types are grouped in “stacks.” A stack is automatically displayed for each evidence
category configured by the organization. The stacks are loaded in the form of an accordion. The
organization can configure the order in which the stacks are displayed within a category, for
example, alphabetically, or most commonly used. The caseworker navigates through the stacks
by clicking the relevant accordion bar.
The system automatically displays the system-generated stacks for each evidence category
configured, an issues stack, and a verifications stack. System-generated stacks cannot be
modified or deleted by the user.
The system supports the use of user-defined stacks. A user can create a new stack and manually
add evidence types to the stacks. A new stack is created by clicking the New Stack accordion
bar, typing the new name, and then dragging and dropping evidence tiles from the other stacks
on to the new stack accordion bar. These user-defined stacks can be renamed and removed. No
other users can access stacks created by another user.
Active and In-Edit Evidence
Notes:
Evidence Relationships
• Parent-Child: Most common

• Multiple Levels: Parent-child-grandchild
• Validations to enforce the relationship
• Using evidence relationships is optional
Notes:
You can create validations to enforce any evidence relationship requirements that you need in a
given implementation of Cúram. For instance, you will probably want to prevent the removal of a
parent evidence record if there are any active child evidence records related to it. Evidence types
can have multiple evidence relationships. For example, an evidence type can be the parent of
one evidence type and the child of another. This is known as a parent-child-grandchild
relationship.
Evidence relationships can be maintained using appropriate validations. For example, the parent
evidence type Property could include a property value. The child evidence type Loan could
include a loan value. These two values could be related to each other in that the sum of all loan
values cannot exceed the value of the property. Validation can be implemented to compare the
sum of the loan values to the property value and stop related evidence records from being
activated if they do not meet the validation requirements.
Evidence Approval Checks
• When a user tries to activate or remove evidence,

the system determines whether the evidence
change requires supervisor approval
• If approval is required, the user is notified that the
evidence cannot be activated or removed until the
case supervisor approves the evidence change
• Approval checks can be configured at four levels in
the Cúram Administration Manager:
1. User
2. Position
3. Organization Unit
4. Product
Notes:
The temporal evidence framework allows you to specify that manual approval is required for a
percentage of changes to a particular evidence type. You enter the evidence approval check
percentage. This specifies the percentage of evidence changes that require manual approval by a
case supervisor. For example, 80 percent of evidence changes for the income evidence type can
require approval. This means that 80 percent of all income evidence records must be manually
approved before they are activated or removed.
The system first checks for evidence approvals for the user. If an evidence approval is not
configured for the user, the system checks the user‟s position, then the user‟s organization unit,
and finally the product delivery case.
Evidence Change History
• Evidence change history starts when a new evidence

record is inserted, and grows when a modification or
cancellation event occurs
• Each entry in the change history contains the type of
change, the date and time of the change, and the
user who made the change
Notes:
Summary

– The functionality of Cúram Temporal Evidence™
– Key temporal evidence terminology
– The temporal evidence maintenance functions provided by the
Cúram Temporal Evidence framework
Notes:
Cúram Administration
6. Cúram Administration
Lesson Objectives

– list and describe some key components of the Cúram
Administration Suite™
– provide an overview of organization and location structure
functionality
– list and describe the elements that determine a user‟s security
Notes:
• Cúram Administration enables you to define and

manage all areas of the Cúram application
• This lesson will focus on the following
administrative components:
– Security
– Organization and Location Structures
– Finance and Calendars
– Code Tables and Rate Tables
– Batch Jobs and Application Properties
– User Interface and Communication Templates
Notes:
Security Administration
• Security administration is divided into two main

categories:
– Authentication
– Authorization
• Authentication ensures that only valid users can
access the application by requiring them to provide
a valid user name and password
• Authorization secures the application once a valid
user has successfully logged in
Notes:
Authentication – “Are you permitted to log in to the application?”
Authorization – “What are you permitted to see and do once you have logged in to the
application?”
Authentication
• Authentication performs the following functions:

– Establishes that a user is authentic based on a valid username
and password
– Verifies that the user's account is enabled
Notes:
Authentication involves several verifications:
Username and password – Authenticates the user by verifying that the user has entered
an appropriate username and password.
Account and/or password expiry – Verifies that the user‟s account is enabled and has not
expired.
User name synchronization with security cache – Ensures username is stored in the
security cache. New users are added to the cache.
Break-in detection – Checks whether unsuccessful logins exceed the upper limit on
password entry attempts, incorrect usernames, and password change failures.
Access restrictions – Checks whether the user is allowed to access the system at the
current log-in time based on that user's access restrictions. User access can be limited to
certain days of the week and certain time periods within the valid days.
Authorization
Notes:
Authorization evaluates user access to secured elements in the application based on their user
security profile, which is defined by a user's security role. Every authorized Cúram user is
assigned a security role. These security roles are at the top level of the security identifier
hierarchy.
Security Identifiers: A security identifier (SID) represents a protected resource. Every secured
element in Cúram is given a unique SID. SIDs can be assigned to business processes; specific
fields on a screen; organization units; locations; case audits; and programs (products, service
plans) offered by the organization. The most common type of SID is the functional SID, also
known as a function identifier (FID). FIDs are used to secure business processes. An example of
a FID is the FID assigned to the Register Person business process. Another type of SID is the
field SID. Field security is used to secure specific information displayed in a field on an
application page.
Security Groups: A security group is the grouping of security identifiers. This level in the security
hierarchy enables you to arrange security identifiers into manageable groups. Users who have a
specific security group assigned to their security role have access to all the resources
represented by the security identifiers belonging to the security group. For example, users are
authorized to register a person when their security role includes the security group that includes
the register person security identifier.
Security Roles: A user has one security role. A security role may consist of several security
groups, which specify the SIDs that a user can access. This includes FIDs, as well as field,
product, service plan, and appeal SIDs.
User Profiles
Security Role Security Group Security ID
Caseworker_Role Caseworker_Group Create Case

Modify Case
Supervisor Role Supervisor_Group Approve Case

Suspend Case
Caseworker_Group Create Case

Modify Case
Notes:
If you were to set up a unique security role for each user, you would have to attribute this security
role to every field, box, and page accessible to that user. As Cúram structures user security
hierarchically, you can avoid this overhead. Each security role is assigned a chosen number of
security groups. Thus, a security role is defined by the combined security access of all of the
associated security groups. Each security group is assigned a chosen number of security
identifiers. Thus, a security group is defined by the combined security access of all of the
associated security identifiers. Each security identifier is assigned a single function, field, or
product within the application. Thus, a security identifier is defined by the security access of the
associated function, field, or product. In summary, users can only access those functions, fields,
and products within their security role.
Location Structure
• Locations are the workplaces of the users

– Also the public offices where citizens can interact with the
organization
• Location hierarchy example:
– State
– Region
– County
– Local office
• Only one location structure may be active at any one
time
Notes:
The locations of the organization are the physical workplaces of its users. All locations have an
address. There can be multiple locations at the same address. For example, there can be
multiple locations within an office building. All locations also have an operating status, which
indicates whether the location is in use. Each location is organized into a hierarchical location
relationship structure with one root location. The location relationship hierarchy is used for
location security, both at the organization and product level. Additional information maintained for
each location includes location holidays; resources, for example, printers and meeting rooms;
child locations; and daily schedules.
Location Data Security Options
• Off
– Users can read/maintain all cases and clients, irrespective of
location
• On
– Users can read/maintain only those cases and clients in the
user‟s location and sub-locations
• Restricted View
– Users can see that cases and clients exist in other locations, but
they cannot read or maintain details
• Read Only
– Users can read (view) details of cases and clients in other
locations, but they cannot maintain details
Notes:
You will find the Location Data Security field on the Organization Home Page.
For Restricted View and Read Only, users can still read/maintain cases and clients in the user‟s
location and sub-locations.
An administrator can grant “Additional Location Access” to a given location. This provides users
with access to data in certain other locations that are not sub-locations of their assigned location.
Location security checks a user's rights to access information based on the location of case and
client information. Location security also checks the location of a user compared to the location of
the case owner, if the case owner is a user. In this situation, access will be granted to a user if the
user's location is successfully compared to either the location of the case owner, or the location of
the primary client of the case.
Location Security Scenario
Notes:
Example 1: If Location Data Security is “On,” User 1 can view and maintain cases and clients only
from Office 1. If Location Data Security is “Read Only,” User 1 can read the case/client details
from Office 3, but cannot maintain (edit) those records.
Example 2: However, if User 1 is assigned to County 1 (not Office 1), he will have full access to
cases from both Office 1 and Office 2.
Sensitivity Security
• Cúram enables you to assign a sensitivity level to

certain data
• Sensitivity levels range from 1 to 5, with 5 being the
highest level
– All sensitivity fields default to 1, but they may be changed
• Users are permitted to view the secured data only if
their sensitivity level is equal to or greater than the
sensitivity level of the data
• Sensitivity security is applied to work queues,
participants, users, and notes
Notes:
All users, participants, notes, and work queues are assigned a sensitivity level. You will see
sensitivity applied to certain other Cúram objects. To access the participant, user, note, or work
queue, the user must have a sensitivity level equal to or higher than the specific data. For
example, if a user with a sensitivity level of 3 tries to view a participant‟s home page, that
participant's sensitivity level must be equal to or less than 3.
Organization Structure
• The organization is a business

model representing the social
enterprise
• Root unit is the highest-level

organization unit in the
structure
• The following components are

defined below the root unit:
– Other organization units
– Positions and jobs
– Users
Notes:
Organization units represent the operational units of an organization, for example, departments,
teams, or groups. You can add an organization unit to the root organization unit or to another
organization unit. You must create the root unit before adding other organization units. An
organization unit can have one or more child organization units. The relationships between
organization units represent the way in which the groups within the organization interact. An
organization unit is the parent element to the positions it contains.
Positions are placeholders for users in the organization structure. Each position is assigned to an
organization unit. You can assign one or more users to a position. Positions also define the type
of work that the users in that position perform, because each position is assigned a job from the
organization's list of jobs. Jobs are the functional roles within the organization. Many positions
can have the same job. Positions can also be lead positions that are used to define the
organization reporting hierarchy. The lead position assigned to the root unit is the primary lead
position for the organization. Note that a position can also be vacant with no users assigned to it.
A user can fill one or more positions in the organization structure. A user‟s assigned position
defines the user's place in the organization reporting hierarchy. It also defines the job that the
user holds. Work can be allocated to users based on their jobs. Note that a user can be created
without being assigned to a position. A user without a position is not represented in the
organization structure and does not have a place in the organization reporting hierarchy. In
addition, the user‟s functional role within the organization is not defined.
Organization Reporting Hierarchy
• The reporting hierarchy is the chain of command

that determines the supervisors in the organization
structure and the users that report to them
• Hierarchy is based on the relationship between
positions and their lead positions
– All positions, except the primary lead position in the root unit,
report to lead positions
– If a position does not have a specified lead position, it reports to
a higher lead position in the organization structure
Notes:
The lead position assigned to the root organization unit is the primary lead position. This position
must be defined in the organization structure before the organization reporting hierarchy can be
implemented. The primary lead position ensures that there is at least one reporting position for all
other positions. If no lead positions are assigned to an organization unit or to any of its parent
units, the unit reports to the primary lead position.
A user's position assignment determines to whom that user reports. Typically, a user reports to
the user assigned to their organization unit‟s lead position. For example, the user John Smith is
assigned to the position of Social Worker 1, which reports to the lead position, Lead Social
Worker. Therefore, John Smith reports to any user assigned to the Lead Social Worker position. If
Jane Doe is assigned to the Lead Social Worker position, she is John Smith's supervisor. If a
user's lead position does not have any user assigned to it, that user reports to the user assigned
to a higher lead position in the organization structure. For example, if there were no users
assigned to the above-mentioned Lead Social Worker position, John Smith then reports to the
users assigned to a higher lead position in the organization structure. The Lead Social Worker
position reports to the root unit lead position. If the Chairman is assigned to the root unit lead
position, John Smith reports to the Chairman.
Example Organization Structure
Notes:
In this diagram, the ovals represent organization units, for example, Board of Directors, Finance,
Investigations, or Eastern District. The diagram also uses the following abbreviations: Lead
Position (LP) and Position (P).
In general, a position reports to the lead position of its organization unit. If the organization unit
has no lead position, or if the lead position is vacant, the position reports to the lead position in
the parent organization unit.
Administering the Organization Structure
• You create an organization structure as part of a

Cúram implementation
• You can also clone an organization structure
• Once you activate the cloned structure, it
supersedes the original organization structure
Notes:
You can make changes to the active organization structure at any time. Since the organization
structure is used in day-to-day business, you should consider the impact of these changes before
implementing them. For example, a user can be removed from a position. Assuming that the user
has no other position assignment, they are no longer part of the organization structure.
Additionally, you can clone an organization structure. You can make modifications to the cloned
structure, while the original one remains intact. Once the cloned structure is activated, it
supersedes the existing active structure. Alternatively, a new organization structure can be
developed in „in edit‟ mode. When it is complete, it can be activated, superseding the existing
active structure. Activating a cloned or new organization structure is useful when the organization
wishes to implement large-scale modifications at one time. For example, the organization may
update user position assignments once a year.
Activities and Financial Administration
• Cúram maintains an activity calendar for the

scheduled activities of the organization
– Activities can be scheduled to occur once-off or to recur at a
specified frequency
• Cúram also provides financial administration
services that enable you to manage the following
organizational components:
– Banks
– Bank accounts
– Exchange rates
– Financial processing calendar
– Insurance return periods
Notes:
The organization calendar is used to record once-off and recurring activities for the organization.
Organization activities apply to all system users and thus will display on the organization activity
calendar, a user's individual calendar, and the equivalent user calendar accessible from a user
home page.
There is a separate financial processing calendar for cash, check, EFT, voucher, and invoice
delivery methods. Each one of these calendars stores the dates on which the organization will not
make payments using the particular delivery method. These dates are called payment exclusion
dates.
An insurance return period is the period for which the organization bills for contributions from
participants.
Product Administration
• Product administration includes the maintenance of

benefit and liability products
• Benefit and liability product administration includes
the maintenance of each product's provisions, rule
sets, and delivery patterns
• Product administration contains the information
necessary for the maintenance of the various case
types, evidence pages, and services available
Notes:
This topic was covered in greater detail in the Case Management module.
User Interface
• Pods
– Administrators can configure new pods, and can select which
pods should be displayed for a given user type
• Quick Links
– Administrators can select which Quick Links are displayed for a
given application view
Notes:
Additional Administration Items
• In Cúram, administration also includes the following

tools and functionality:
– Nicknames
– Batch processes
– Code tables
– Properties
– Rate tables
– Communication templates
Notes:
Nicknames
• The system administrator manages a thesaurus of

nicknames, for example, William, Will, Bill, Billy
• Nicknames can be used as search criteria for
persons and prospect persons
– If nickname search is performed, results include records that
match the entered name as well as any associated nicknames
Notes:
Batch Processes
• Batch processes are executables or mini-programs

that process a large number of records according to
set parameters
– DetermineProductDeliveryEligibility is a batch process that
checks eligibility and activates a case
• They are often scheduled by organizations for off-
peak times, for example, nights or weekends
Notes:
You can define the values for set parameters when submitting a batch process.
Batch process error codes allow you to specify the error codes returned by the Cúram Batch
Launcher in the event of a batch process failure.
Batch Process Groups organize batch processes into logical groups.
Code Tables
• Code tables store items that display in Cúram drop-

down lists
• Code table items consist of codes and
corresponding descriptions
• Parent-child relationships between code tables can
be established (code table hierarchy)
• Code tables enable the localization of drop-down
lists for different language and location
requirements
• Newly added code table items must be published in
order to display on their associated drop-down lists
Notes:
Example: The Country code table contains all of the countries of the world.
Properties
• Application properties are variables that are used by

the system in various ways
– They configure the system to suit the organization‟s needs
– Examples: Date format, default currency, and database type
• Information maintained for each property includes
the current value, the default value, and the category
of the property
• Categories enable you to group related property
types
Notes:
An example of such a variable is the property that denotes the default date format used by the
application (curam.misc.app.defaultdateformat). The value of this property can be Date_mdy_ext
(month-day-year) or changed to Date_dmy_ext (day-month-year).
Rate Tables
• Rates are values that can vary over time

– Age limits
– Maximum income amounts
• Rate tables are used to maintain these rates
• Rate tables are used by rule sets
– When rates change, you change them in the rate tables rather
than coding them directly in the rule sets
• Rate tables are effective-dated
Notes:
A rate table can contain an indefinite number of rows and columns. The values of individual rates
are stored in table cells. Additionally, you can add sub-rows and sub-columns to each individual
row and column. You can also clone a rate table and use it as the basis for a new table. Each
rate table has a type and effective date. Note that if two rate tables have been created for the
same type, the effective date of the rate tables continues until midnight of the day before the
effective date of the next rate table.
Communication Templates
• You can create communication templates to

standardize the communications issued to
correspondents, for example, application forms and
registration acknowledgment letters
• Cúram supports two communication templates:
– Extensible Style Language (XSL)
– Microsoft Word
• Templates can be associated with specific types of
participant or case
– Only appropriate templates will be displayed
Notes:
XSL templates are used to automatically generate bulk communications, often through batch
processing. An XSL template includes standard text that displays on communications generated
from the template. It also includes variables that refer to existing data, such as the
correspondent's name, address, case number, and identification number. This data is stored
separately from the template. As part of pro forma communication generation, the variables in the
template are populated with data stored in the Cúram Server.
Like XSL templates, Microsoft® Word templates can be used to create several communications
from the same template. However, the creation of a communication from a Word template is done
manually. A business user can create a communication based on a Word template and make
necessary modifications to the communication before issuing it. For example, if the business user
had a phone conversation with the correspondent before creating the communication, the details
of that conversation can be added to the communication text.
Summary

– Security
– Organization and Location Structures
– Finance and Calendars
– Code Tables and Rate Tables
– Batch Jobs and Application Properties
– User Interface and Communication Templates
Notes:
Cúram Financial Management
7. Cúram Financial Management
Cúram Financial
Management
Lesson Objectives

– describe the Cúram Financial Management™ functionality that
processes payments, liabilities, and payments received
– list and describe Cúram‟s financial building blocks
– identify the three deduction categories
Notes:
Cúram Financial Management™
• The basic units of Cúram Financial Management™

are payments, liabilities, and payments received
– A payment is an issue of funds from the organization to a
participant who is eligible for a benefit product
– A liability is a charge for funds from the organization to a
participant who is eligible for a liability product
– A payment received is an amount of money received by the
organization, usually sent in response to a bill
Notes:
An example of a payment could be a $300 check issued to a person eligible for unemployment
insurance benefits. Payments are also generated for participants when the organization has paid
them too little or billed them too much. For example, if the person above should have been paid
$325, an underpayment is created to pay the person the additional $25 due.
An example of a liability might be an invoice for $100 issued to an employer liable for employer
contribution payments. Liabilities are also generated for participants when the organization has
paid them too much or billed them too little. For example, if the employer above should have been
billed $125, an under-billing is created to bill the employer the additional $25 due.
Payments received are used to pay off liabilities. Unlike payments and liabilities, payments
received are not generated as part of case processing. Instead, they are recorded on the system
either manually by a user or via a batch process that records payments received in bulk, for
example, all payments received by EFT from a particular bank. Payments received are
associated with a person's financials through the allocation of the payment received toward one
or more outstanding liabilities.
Financial Building Blocks
• Cúram Financial Management manages the following

core building blocks:
– Financial Component
– Instruction Line Item
– Financial Instruction
– Financial Instrument
– Payslip
Notes:
Financial Component
• Financial components are schedules to pay or bill in

relation to a case
• The following information is included in a financial
component:
– Category: Determines whether the financial component is a
payment or liability
– Primary client: The client for whom entitlement to payment or
liability was calculated
– Case nominee: The recipient of a payment or bill
– Amount to be paid or billed
– Delivery pattern: Indicates the delivery method and frequency
– Start date and end date for the payment or billing schedule
Notes:
A sample financial component might indicate that John Smith should receive $25 per week in
payments by check from January 1st through April 1st. A financial component is generated from a
case component if the primary client is determined to be eligible for the case component. Case
components are the benefits or liabilities that a primary client might be eligible for, for example,
personal benefit or employer contribution liability. Financial components are also created as part
of reassessment processing. That is, financial components are created for overpayments or
underpayments that have been issued on a case. For example, John Smith is originally paid $25,
but a change in evidence makes him eligible for $40. A financial component with an amount of
$15 is created to rectify the underpayment.
The default case nominee for all case components is the primary client. However, a case
nominee can be any individual or party designated to receive a case component on behalf of the
primary client. You can define an offset for a delivery pattern. An offset determines the number of
days prior to the due date that a financial transaction needs to be processed for the payment to
reach the participant on time.
Secondary financial components are schedules to make deductions from payments. They are
created when deductions are set up for benefit cases. Secondary financial components are
processed when case payments are issued. The amount of the deduction is checked against the
total case payment amount to ensure that the correct amount has been deducted.
Instruction Line Item (ILI)
• A financial instruction line item (ILI) is the most

basic financial processing element in Cúram
• Represents a single payment or bill for an individual
financial component of a specific product delivery,
for example:
– Pay James Smith $200.00 on March 14th
– Deduct $15.00 from James Smith‟s benefit to pay his electricity
bill
Notes:
ILIs are created for a case when financial components are processed. Whereas a financial
component is a schedule to pay or bill, an ILI for a case is one instance of that schedule, a
payment or bill. For example, a financial component schedules John Smith to be paid $25 by
check every week, starting on January 1st. On January 1st, the financial component is actually
processed into a financial ILI. A financial ILI is thereafter created every week until the end date of
the financial component. Information carried over from the financial component includes the
nominee, the delivery pattern, the amount, and the period of time the payment or bill covers.
Note that financial instruction line items can also be created outside of case processing. For
example, financial instruction line items are created when a payment received is allocated toward
a liability, when a manual payment is captured, when a liability is written off, and so on.
Financial Instruction
• Consolidation of ILIs into a single transactional unit

of financial processing
• Allows single payment issuance of multiple product
components
• Useful for bulk payment or billing
– Utility companies
– Service providers
• An example of a financial instruction might read as
follows:
– Pay James Smith $185.00 ($200 benefit minus $15 deduction)
Notes:
A financial instruction is a rolled up view of one or more instruction line items. Rolling-up refers to
the process of consolidating several ILIs of the same category, nominee, delivery method,
currency, and cover period. The rolling up of instruction line items into a single financial
instruction consolidates a nominee's instruction line items of the same category into a single
financial instruction. Rolling up may also be used to consolidate a number of payments or
liabilities for a nominee. For example, an instruction representing four separate payment
instruction line items may be created and issued to a nominee as a single payment. Rolling up is
useful because it simplifies the organization's financial interactions with participants. For example,
a payment instruction might include the maximum personal instruction line item rolled up with any
deduction instruction line items, for example, third party deductions.
Financial Instruments
• Financial instruments are the records of actual

payments, liabilities, or payments received that have
been issued or received by the organization
• They are recorded for financial instructions
• For example, a payment instrument is recorded
when a payment instruction is issued for a person
• Data from financial instruments can be used to
interface with external financial systems, such as a
check-writing system
Notes:
Payslip
• A record of the ILIs that pertain to a particular

payment or liability instruction
• Payslips may be issued to a participant, case
nominee, or third party for recordkeeping purposes
• Payslips contain the following components:
– A header with recipient details
– Payment or liability details
– A section containing details of each ILI in the payment or liability
Notes:
Generating Payments and Liabilities
Notes:
Payments and liabilities can be generated automatically or manually. Payments and liabilities due
for active cases are automatically generated when the Financial Batch Suite runs. The Financial
Batch Suite is a group of four processes that are executed in sequence. Running these
processes at a regular frequency (for example, nightly) automates payment and liability
generation and ensures that eligible participants are paid or billed according to their delivery
frequency. The Determine Product Delivery Eligibility batch process generates financial
components. The Generate Instruction Line Items batch process runs second to generate ILIs.
The Generate Instruments batch process runs third to generate financial instructions and financial
instruments. The Generate Payslips process runs fourth to generate payslips for all financial
instruments.
Payments can be generated online for a single benefit case without the Financial Batch Suite
having to be called. This may be necessary if the primary client is in need of emergency
assistance. Payments can be generated online only for active cases.
Deductions and Adjustments
• Deductions and adjustments are processed when

payments and liabilities are generated
• Deductions and tax adjustments are taken from
benefit payments
• Three deduction categories
– Applied
– Unapplied
– Third party
• Surcharge adjustments are added to liabilities
Notes:
Tax adjustment processing is set up at the benefit product level. This means that taxes are
applied to all payments for this benefit. When financial components are created for a benefit,
information regarding whether tax adjustment processing is required is saved on each of the
financial components.
Surcharges are additional charges applied to liabilities that have not been processed within an
appropriate time period. For example, suppose that an employer is issued a bill for employment
contributions and does not pay all or a portion of this bill within the appropriate time period. A
surcharge is applied to the outstanding amount. The employer is issued a new bill for the
surcharge. Like tax adjustment processing, surcharge adjustment processing is set up at the
product level.
Applied Deduction
• An applied deduction is an amount deducted from a

Person's benefit payment and used to pay off an
outstanding liability owed to the organization
• Applied deductions can be allocated to liabilities
incurred by the primary client or by any other
participant
– For example, part of a Person's benefit payment can be
allocated to a liability incurred by another member of the
household
Notes:
Unapplied Deduction
• An unapplied deduction is a stand-alone deduction

amount that is not applied toward a specific liability
• For example, an amount is deducted from a Person's
benefit payment and used to make a general refund
to the organization
Notes:
Suppose that a claimant is in receipt of a benefit but has not provided all of the information that
the organization requires. The failure to provide all required information triggers a punitive
reduction of the benefit amount. The reduced benefit is the result of creating an unapplied
deduction on the benefit amount. The deducted money is not applied to an existing liability. The
unapplied deduction is used as a penalty until such time as the claimant provides the information
that the organization requires. Once the information has been provided, the unapplied deduction
can be removed.
Third-Party Deduction
• An amount deducted from a Person's benefit payment

and used to pay off charges, costs, or debts owed to
another participant (not the organization)
• Can be issued to the following Cúram participant types:
– Person
– Employer
– Service Supplier
– Product Provider
– Information Provider
– Utility
– Representative
Notes:
For example, a person can allocate part of his benefit payment toward an electricity bill. Third-
party deductions can also be used to pay off unpaid fines, compensation orders, or child support
orders.
Deduction Maintenance
• Deductions are maintained on a case-by-case basis

– Deductions cannot be deducted from case payments unless a
user specifically creates the deduction on the case
• A user can set up one or more deductions on an
individual case
– The deduction priority dictates the order in which the deduction
is processed when payments are generated for the case
• Two types of deduction
– Fixed (specific monetary amount)
– Variable (percentage)
Notes:
A fixed deduction must be assigned to a single nominee within the case. However, a variable
deduction can be assigned to a single nominee, all nominees, or a case component.
Each deduction has a status that describes its progress. There are five deduction statuses:
inactive, active, processed, skipped, canceled.
Payment Processing for Deductions
• The frequency of deductions is per benefit payment

• Deductions are processed in the specified order of
priority
• If there is an insufficient amount remaining on the
benefit payment to process the full deduction
amount, the following options are available:
– Deduct nothing (Skip the deduction)
– Deduct remaining (Whatever amount remains)
Notes:
Recurring deductions occur on a per-payment basis rather than a temporal basis, such as
weekly, or monthly.
Other Payment Functions
• Canceling a payment
• Invalidating a payment
• Regenerating a payment
• Approving a suspended payment
• Capturing a manual payment
Notes:
You can cancel a payment issued in error, or that has not been received. Invalidating a payment
means that it should no longer be considered by system processing. This is to allow for the
regeneration of a replacement payment if, for example, the original payment was issued for the
incorrect amount. You can cancel and invalidate a payment at the same time. A canceled
payment can be regenerated, which creates a new payment instruction and ILIs.
The system administrator can set a maximum payment amount for a delivery pattern. Payments
exceeding this maximum are suspended. Approving a suspended payment overrides this
limitation and allows the payment to be issued.
A manual payment is a payment to a case nominee that is issued outside of Cúram. Information
regarding that manual payment must be captured on the system. Capturing the manual payment
calls processes that recreate all the elements of a payment. These elements include the payment
instrument, payment instruction, rolled-up ILIs, and any relevant deduction or tax ILIs.
Other Liability Functions
• Reversing a liability means that the nominee is no

longer responsible for the liability amount
– For example, if an employer is billed incorrectly, the incorrect
liability can be reversed so that the employer no longer owes the
liability amount
– A new reversal instruction is created to cancel the amount of the
liability
• Writing-off a liability means that the participant is
unable to pay
– For example, if a person declares bankruptcy, all or a portion of
that person's debt to the organization can be written off
Notes:
When a liability instruction line item is reversed, the liability amount is negated rather than deleted
from the system. This is for accountability and traceability purposes. A new reversal instruction
line item is created to cancel the amount of the liability instruction line item. The reversal
instruction line item is automatically allocated toward the liability instruction line item. This
updates the outstanding amount of the liability instruction line item to zero. The reversal
instruction line item is rolled up into a reversal instruction.
When a liability instruction line item is written off, a write-off instruction line item is created to
reflect the write-off amount. This creates a record of the write-off that is useful for accountability
and traceability purposes. The write-off instruction line item is automatically allocated toward the
liability instruction line item. This reduces the outstanding amount of the liability instruction line
item by the amount of the write-off.
Receiving Payments
• Payments can be received from

– Persons
– Employers
– Unknown sources
• Temporarily recorded in a suspense account
• Payments received can be allocated to liabilities

– Can allocate all or portions of collected money to one or many
liabilities
– Cúram allows allocation of deductions (applied and third-party)
to existing liabilities
Notes:
Any payment received by the organization must be recorded on the system. A payment may be
received in respect of a registered employer or person. Your organization may also receive
payments from an unknown origin. When a payment is received from an unknown source, that
payment is recorded in a suspense account until the organization can determine its issuer and
purpose.
When capturing payment details for an employer or person, the system requires the amount, date
received, and effective date of the payment. It also captures the method of receipt, type of
currency, a reference number, and issuer details. Payments can also be received in batch mode.
An allocation is a funds transfer to an outstanding liability. The system allows you to collect basic
information about the amount of money being collected for allocation and select the appropriate
liability against which to allocate the collected money. The system allows manual entry and
allocation of some or all of the collected money.
Summary

– Functionality of processing payments, liabilities, and payments
received
– Cúram‟s financial building blocks
– Deduction categories and processing
Notes:
Cúram Outcome Management
8. Cúram Outcome Management
Cúram Outcome
Management
Lesson Objectives

– describe Cúram Outcome Management and how it helps an
SEM agency to achieve better outcomes for its clients
– explain how assessments are used to provide a picture of a
client‟s circumstances and to make recommendations
– build an outcome plan to achieve positive outcomes
Notes:
What is Outcome Management?
A citizen-centric approach to service delivery
• Provides the organization with

the ability to run different types
of assessments to identify the
root causes of a client‟s issues
and needs
• Focuses on the benefits that
the services provide to citizens
• Utilizes collaborative planning
towards a clearly defined end
result
• Measures effectiveness in
terms of citizen outcomes
Notes:
Outcome management is a citizen-centric approach to service delivery that targets the results a
citizen needs to achieve, rather than simply listing the available services. Outcome management
adopts a collaborative approach that enables social enterprise management (SEM) agencies to
exploit the expertise of individuals within their own ranks, and also to harness relevant knowledge
and skills within other organizations, such as external service providers. Traditional approaches
lead to citizens not receiving the right help at the right time, which can increase their duration of
dependence on a given agency. In addition, individual agencies working independently may lack
the expertise required to identify citizens‟ needs accurately. Outcome management enables an
agency to select the appropriate products or services for a citizen, irrespective of whether they
are provided in-house or by another agency. This results in better outcomes for the citizen. The
delivery of services to a citizen is managed via a multi-agency, multidisciplinary approach that
can provide the diversity of products and services required to create the conditions for successful
achievement of a given outcome.
Outcome management requires collaborative planning towards a clearly defined end result.
Planning begins with a clear understanding of a citizen‟s needs and the specific changes sought
by citizens. This enables a planner to identify critical steps or objectives that citizens must take to
achieve a specific change in behavior, knowledge, skills, condition, or status.
Outcome management focuses on the benefits of services to the citizen (outcomes) instead of
the inputs and processes of the services themselves. It fits services to citizens, rather than
citizens to services. It measures the effectiveness of service delivery by the achievement of
citizen successes or changes, in other words, citizen outcomes.
Functional Components
• The two major functional components of Outcome

Management are…
1. Assessments
2. Outcome Planning
Assessment Outcome Desired

Planning Outcome
Notes:
Assessments provide SEM agencies with a mechanism for managing the identification of citizen
needs. Outcome Management enables the organization to run different types of assessment to
identify the root cause of a citizen‟s issues and needs, for example, caregiver strengths and
needs, self-sufficiency, and safety assessments. Once the agency identifies a citizen‟s needs,
outcome planning can be used to create a plan that addresses them.
Outcome Planning provides tools to facilitate the identification, scheduling, and maintenance of
appropriate activities to achieve citizen goals and objectives. Goals and objectives represent the
citizen‟s outcomes. Outcome planning provides an environment in which the caseworker can
create a structured plan that identifies and delivers the precise set of activities required to achieve
the desired outcomes for one or more citizens. Outcome planning provides the means by which
the issues or needs identified during assessment are addressed. In other words, outcome
planning is the link between assessment results and the activities used to address the identified
issues.
Assessments
• Used to identify the root cause of issues or needs of

the client
• Configured in the Cúram Administration Suite™ as
an assessment definition
• Individual or group-based
• Use IEG, CDA, CER
• Consist of:
– Types
– Factors
• Categories and classifications
– Roles
Notes:
An assessment definition is an assessment template that is used by the agency to develop
different assessment types. For each assessment definition, configuration enables the
administrator to specify how the assessment data is collected and how assessment results are
determined. In practice, Cúram Intelligent Evidence Gathering™ (IEG) is used to collect data in
the form of a question script, while Cúram Decision Assist™ (CDA) or a Cúram Express Rule
(CER) set can be used to determine the assessment results.
There are several other configuration settings, such as whether the setting of priority factors is
applicable to an assessment, whether reassessment is allowed, and how the assessment results
are displayed. You can also specify whether the assessment is used to assess a group or
household of citizens, or to assess citizens individually. By assessing a group of citizens,
questions are asked once and apply to the entire group, with results being displayed for the
group. Assessments can also be associated with cases.
Assessment Types
• Different types of assessment are used to identify

the root cause of a client’s needs
• Examples include:
Family
Self-
Strength Safety
Sufficiency
and Needs
Notes:
Assessment Factors
• A factor is an aspect of client circumstances of

interest to an agency
• Citizen needs are assessed using factors
• Categories:
Need Barrier
Parenting Substance Domestic Mental

Education
Skills Abuse Violence Health
• Categories have an associated Classification

Safe Progressing Engaged Vulnerable
(0 to 2) (3 to 5) (6 to 8) (9 to 10) - Can assign ranges
Notes:
Typically, a factor is categorized as either a need or a barrier. Needs are things that a client or
family require to be self-sustaining, but currently lack , for example, parenting skills or education.
Barriers are conditions that prevent or complicate a client's ability to obtain or achieve something,
for example, substance abuse, domestic violence, and mental health.
Agencies typically assess clients and/or families to measure their current situation in relation to
one or more factors. Factors are assigned to a category and thus adopt the category
classification.
Categorizing and Classifying Factors
1..n
Assessment 1..n
Factors Classifications
Definition
Family Strength & Needs Assessment Self-Sufficiency Assessment
Safe
Strength
Substance Domestic Progressing
Abuse Violence
Need Engaged
Vulnerable
Family Strength
Parenting Self-
Strength &
Skills Sufficiency
Needs Need
Safe
Strength Progressing
Mental Housing
Health Engaged
Need
Vulnerable
Notes:
An assessment definition can have one or more factors. Factors can have one or more
classifications. Classifications are specified for each category. All factors must fall into a particular
category (need or barrier), and all classifications defined for that category will be applicable for
the factor. So, at the factor level, you cannot enter different classifications.
Assessment Roles
• An assessment role is the part played by a citizen in an

assessment
Roles Assessment Factors Circumstances
Primary
Strength
Caregiver Substance
Role Abuse
Need
Focus Family Strength

Child Parenting
Strength Skills
Role & Needs Need
Secondary Strength
Mental
Caregiver Health
Role Need
Notes:
There must be at least one role specified for an assessment before it can be run. Multiple roles
can also be configured. A role can be configured to allow multiple citizens to fill that role during an
assessment.
Roles in an assessment can be specified as mandatory, that is, at least one citizen must be
specified for the role before the assessment can be carried out by a caseworker. Administrators
can specify whether questions are applicable to a role. If the administrator specifies that certain
questions should not apply to a role, these questions are not presented to the citizen fulfilling that
role during the assessment. The order in which roles are processed in an assessment can also
be changed.
Assessment Questionnaire
Notes:
Once the clients and roles have been selected for the assessment, the next step in running the
assessment is to capture information about the client's situation. The information is captured
using a predefined question script that is specific to the type of assessment being run. The
question scripts are created using IEG. With IEG, information is gathered interactively by
displaying a script of questions that a caseworker can provide answers to.
Depending on how the assessment has been configured, questions can be asked of all clients
being assessed, or a subset of clients. For example, in the Caregiver Strength and Needs
Assessment, questions are asked of the primary caregiver and the secondary caregiver, but not
of the focus child. Additionally, an assessment may be configured to assess a group of clients. As
such, one set of questions is asked of the entire group, for example, a Risk Assessment
assesses a group of clients.
Assessment Results
• Assessments are used to determine a client’s

circumstances by producing a set of results that
defines the client’s circumstances for one or more
factors
• CDA (Decision Matrix) or CER used as the
“assessment engine” to determine the assessment
results
– CDA for simple assessments
– CER for more complex assessments
IEG Answers Decision Mapped

Factor
Question Matrix Factor Classification
Script or CER
Notes:
For each assessment definition, configuration enables the administrator to specify how the
assessment data is collected and how assessment results are determined. In practice, Cúram
Intelligent Evidence Gathering™ (IEG) is used to collect data in the form of a question script,
while Cúram Decision Assist™ (CDA) or a Cúram Express Rule (CER) set can be used to
determine the assessment results.
Mappings are defined between a factor and the output from the assessment engine. If using
scoring, the range is used to map the score to the appropriate classification. CDA outcomes can
be mapped directly to factor classifications if scoring is not used.
Viewing Assessment Results
Notes:
The assessment results are automatically displayed when the assessment script is completed.
Depending on how the assessment is configured in application administration, the assessment
results are displayed either in a list or as a graph.
Recommendations
• Recommendations are suggestions of activities

(services, actions, or referrals) targeted to address a
client’s specific circumstances
• They are based on the assessment results
Assessment Factor Circumstance Ranges Recommendations
Strength 3 to 5 Service A
0 to 5 0 to 2 Referral A
Family
Substance
Strength &
Needs Abuse
Service B
Need
Referral B
-5 to -1
Action A
Notes:
Recommendations can be configured based on different ranges assigned to factor
circumstances.
Working with Recommendations
Caseworker can drag recommendations

onto the activity calendar.
Notes:
In developing an outcome plan, the caseworker can see the system recommendations for the
client on the Activity Workspace tab of the Outcome Plan page. The caseworker can then drag a
recommendation from the recommendations panel on to the activity calendar to schedule the
recommended activity into the outcome plan.
Outcome Plans
• Outcome Plans are used to manage the provision of

activities to address the client’s particular
circumstances in order to achieve a specific goal
• Components of outcome plans include:
Goals Objectives Factors

Activities Participation Recommendations
Activity Workspace Agreements Reviews
Associated MDTs Collaboration
• May be created from an Integrated Case or in a

standalone fashion
Notes:
Outcome plans are configured using the administration suite. Once outcome plan templates have
been defined, actual plans can be created by the caseworkers to identify and address citizen
needs.
Outcome Plan Goals
• The result or outcome that the plan is intended to

achieve for one or more clients
– Self-sufficiency
– Reunification
– Adoption
• A goal can be specified for an outcome plan or for
each citizen in an outcome plan
• Goals are defined using the Cúram Administration
Suite and associated with types of Outcome Plan
• An expected end date for each goal must also be
specified
Notes:
Goals are defined by an administrator and then shared across multiple types of outcome plan
template. Goals can then be added to an outcome plan by a caseworker. An overall goal can be
specified for an outcome plan, or a goal can be specified for each citizen in an outcome plan.
Each outcome plan is created to assist a citizen in achieving a goal. For example, a Self-
Sufficiency plan is created to achieve the goal of returning to work. The goal represents the
primary objective that a citizen is working towards to become independent of the organization.
Goal Tab
Notes:
In the above screen, the goal is Self Sufficiency for James Smith. The goal tab contains additional
tabs, including Home, Progress, Reviews, Notes, and End Date History. The caseworker can
view, edit, or update the progress of the goal.
Outcome Plan Objectives
• Objectives are items that, if achieved, help to

accomplish the plan goals
– Lead a healthier lifestyle
– Remain clean and sober
• The objectives that can be selected are configured
as part of outcome plan administration
• Caseworker can also specify
the name of an objective
Notes:
Objectives are defined by an administrator and can be shared across multiple types of outcome
plan. Objectives are smaller steps that can be undertaken by a citizen in order to achieve the
outcome plan goal. For example, the objectives for a citizen on a Back to Work outcome plan
may be to Improve Basic Education or to Remain Clean and Sober. Once objectives have been
defined in the administration application, they can then be added to an outcome plan by a
caseworker.
Objectives are associated with factors, which enables the caseworker to identify the activities
being undertaken to achieve the objective.
Objectives Tab
Notes:
In the above screen, the objective is for James and Linda Smith to remain clean and sober. The
objectives tab contains additional tabs including Home, Progress, Reviews, Activities, Factor
History, Notes, and End Date History. The caseworker can view, edit, or update the progress of
the objective.
Outcome Plan Factors
• A Factor is an aspect of client circumstances that

may be defined by an associated rating
Substance Domestic
Education
Abuse Violence
• May be added to an outcome plan…

– As a result of an assessment, for example, self-sufficiency, or
family strengths and needs
– Selected from a predefined list of appropriate factors
– Defined by a case to specially address a particular circumstance
(configurable)
• Caseworkers can set priority rating for factors
Notes:
Priority ratings factors help to identify where the most serious and pressing issues lie, or where
the most may be gained by applying resources to the problems, or even to the strengths.
Factor Tab
Notes:
In the above screen, the factor is substance abuse for James Smith. The factor tab contains
additional tabs, including Home, Progress, Activities, Guidance, Priority, Notes, and Attachments.
The caseworker can view, edit, or update the progress of the Factor.
Outcome Plan Activities
• The items undertaken to address the client’s circumstances
SERVICES
REFERRALS
ACTIONS
Notes:
Activities are defined by an administrator and can then be added to an outcome plan by a
caseworker. They do not have to be associated with a type of outcome plan in administration
before they can be added to an outcome plan. Activities are added to an outcome plan to address
the issues or needs identified during assessment. For example, Alcohol Abuse Counselling can
be added to a plan to address issues with substance abuse. Activities can be recommended by
Outcome Management based on the assessment results. In turn, the caseworker can choose to
add these activities to a plan. Alternatively, a caseworker can search for and add an activity to a
plan. There are three types of activity that can be defined and subsequently added to a plan:
services, referrals, and actions.
Services
• Delivered by a third party (or agency)

• Paid for and tracked by the agency
• Use services defined in the CPM service registry
• Can configure approvals for services
Notes:
A service is an activity provided to a client by a third party provider, but paid for and tracked by
the SEM agency, for example, Alcohol/Drug Abuse Day Treatment. Services must be defined in
the Cúram Provider Management™ (CPM) services registry before they can be added to an
outcome plan. Outcome Management provides several service offering configuration options.
These options enable you to define the information that can be specified when creating the
service, such as whether a provider or provider type is mandatory when creating a service,
whether the service is appropriate for multiple clients, whether the user can specify the frequency
of service, whether participation tracking is required, and whether the user can specify the rate to
be paid to a provider for providing this service.
Referrals
• Hand-off by the agency to a third party

• Usually not tracked by the agency, but includes a
reminder to follow up
• Uses referral services in CPM
• Client and provider notification letters
can be produced
– Email or postal mail
Notes:
A referral is a facility provided to a client by a third-party provider, but not paid for by the agency,
for example, physiotherapy sessions. As with services, referrals must be defined in the CPM
services registry before they can be added to an outcome plan. Referrals allow for notifications to
be sent to the client being referred and to the provider offering the service. Service offering
configuration options enable you to specify a range of settings, such as whether the referral
service is appropriate for multiple clients. You can also specify templates that can be used to
produce the referral notifications sent to the client and the provider.
Referrals
• Wizard used to add a referral to an outcome plan
– Appearance and behavior is dependent upon referral configuration
Notes:
Actions
• Anything that is not a service or a referral

– Daily exercise
– Join a book club
• Agency can track cost
Notes:
An action is an activity deemed not to be a service or a referral that can be added to an outcome
plan, for example, Daily Exercise. Actions need to be defined in Outcome Management
administration before they can be added to an outcome plan. As with services and referrals,
several configuration options control the information that can be specified when adding an action
to an outcome plan. These options include whether the action is appropriate for multiple clients,
whether there is a cost associated with the action, whether participation tracking is required, and
whether the citizen or the user should be responsible for the action.
Actions
• Wizard used to add an action to an outcome plan
– Appearance and behavior is dependent upon action configuration
Notes:
Participation
• Used to record the number of hours a client spends

on a particular activity
– Absence may also be recorded
• The Cúram Administration suite is used to specify
whether participation is appropriate for a particular
activity
• May be recorded directly onto the outcome plan or
received from provider attendance records
• The caseworker may also project expected
participation for a particular activity
Notes:
Activity Workspace
• Central area for developing and maintaining the

Outcome Plan
– Content Panel (left)
• Timeline View – Daily, weekly, and monthly view of activities
• Analysis View – Visual representation of the Outcome Plan
– Recommendations Panel (right)
• Contains plan and factor-level recommendations and recently
added non-recommended activities, for example, guitar lessons
– Details Panel (bottom)
• Displays details of an activity selected in the timeline
Notes:
The activity workspace enables a caseworker to easily access recommended and recently added
activities, to quickly schedule new activities, and to have a central view of all activities currently
scheduled for clients within an outcome plan.
Activity Workspace
Notes:
Client Agreements
• Agreement between one or more clients and the SEM

agency
• Agree in writing to all elements of the plan
• Agreement can be changed up until the point where
it is marked as complete
• Once complete, the agreement may be issued to
clients for signing
– Date signed can be recorded
on the system
– The agreement can be
scanned and stored as an
attachment
Notes:
Once the caseworker and the client have agreed to all elements of a plan, they agree in writing to
adhere to the activities outlined within it.
Monitoring Client Progress
• Reassessment
– Reassessment allows the agency to re-run assessments in order
to identify current needs and monitor progress over time
• Reviews
– Reviews can be set up that allow the caseworker to assess the
suitability and appropriateness of Activities, Goals, and
Objectives
• Outcome plan analysis view
– Displays the outcome plan clients, objectives, factors, activities,
and the relationships between these elements
– Obtain a holistic view of all of the elements of an outcome plan
Notes:
Outcome Plan Analysis View
Notes:
The diagram above shows an example of a Family Reunification plan. Each client has been
assessed for a number of factors , including Substance Abuse, Parenting Skills, and Education.
Activities have been added to the plan to deal with one of the client's Substance Abuse issues, for
example, Alcohol Abuse Treatment – In Patient.
Multidisciplinary Teams
• Multidisciplinary teams (MDTs) drawn from inside

and outside the organization are equipped to identify
the optimal course of action
• MDTs work closely with the caseworker
• Professions typically represented on MDTs include…
Police Teacher Caseworker Doctor Financial Expert
Notes:
The MDT can work with caseworkers to resolve difficult cases by promoting coordination between
agencies and identifying service gaps and coordination breakdowns between agencies and
citizens. The MDT can also provide a forum for learning more about the strategies, resources,
and approaches used by other disciplines. Professional disciplines that are typically represented
on MDTs include child and adult protective services, the civil and criminal justice systems, health
and social services, and mental health services. Some teams include domestic violence
advocates, substance abuse specialists, clergy, and policy-makers. Financial abuse specialist
teams focus on cases involving exploitation, and include representatives from financial
institutions, including banks or credit unions, stock brokerage firms, mortgage lenders, and
private trustees or guardians.
Collaboration
• Administrator defines if collaboration is enabled

– If so, can associate an MDT with the Outcome Plan
• The following information is sharable:
– Services
– Actions
– Referrals
– Notes
– Attachments
Notes:
A Multi-Disciplinary Team (MDT) member can only view information that has been shared with
the member.
Summary

– Overview of outcome management
– Assessments
• Types, Factors, Roles, Questionnaire, and Results
– Outcome Plans
• Goals, Objectives, Factors
• Activities
– Services, Referrals, Actions
• Recommendations, Participation
• Collaboration, Associated MDTs
• Agreements, Reviews
Notes:
Cúram Case Audit
9. Cúram Case Audit
Cúram Case Audit
Cúram Case Audit
Lesson Objectives

– define Cúram Case Audits and provide a high-level overview of
case audit processing
– understand how case audits are used to monitor the delivery of
the organization's benefits and services
– describe the processing that is involved in carrying out the case
audits
Notes:
Cúram Case Audit
What are Case Audits?
Social Enterprise Management (SEM) agencies perform

case audits to monitor the delivery of benefits and
services to the clients
• Two types of audit
– Quantitative: Measures compliance
with legislation and policy
– Qualitative: Measures and assesses
case outcomes
• The selection of cases to audit
is typically done by generating
a random list of cases
Notes:
Social Enterprise Management (SEM) agencies perform audits of cases on a regular basis to
measure their success in working with children and families. The objective of auditing is
performance improvement. In general, auditing is either quantitative or qualitative. Quantitative
auditing usually measures an agency‟s compliance with specific federal or state regulations.
Qualitative auditing usually operates on a more ad hoc basis, seeking areas in which general
performance improvements need to be made.
Agencies need a way to easily create and manage audits. Agencies need to create audit plans,
specify the selection criteria to be used in generating a random sample of cases, and document
the findings for each case being audited. In turn, the findings from the case audits are used to
analyze or track error trends and identify areas to focus on for the next period of case audits.
Cúram Case Audit
Case Audit Life Cycle
1. Create case audit configurations – Administrator

2. Create case audit plan – Audit coordinator
3. Produce case sample list – Audit coordinator
4. Assign auditors – Audit coordinator
5. Record audit findings – Auditor or audit team
6. Provide feedback – Case owners and supervisors
7. Record summary findings – Audit coordinator
8. Record recommendations and action items – Audit
coordinator
Notes:
Create Audit Plan – The audit coordinator creates a plan to define the expected scope,
goals, and conduct of the audit. The audit plan is then given a schedule, and auditors
added to the plan.
Produce Case Sample List – A list of cases to be audited can be generated randomly, or
alternatively, by manual selection.
Assign Auditors – Once a list of cases has been added to the plan, auditors are assigned
to each individual case for audit.
Record Audit Findings – Auditors document their findings against the focus areas as
detailed in the audit plan.
Provide Feedback – If required, the case owners and supervisors are sent notifications.
Record Summary Findings and Recommendations – Once all cases associated with the
audit plan have been audited and feedback provided, the audit coordinator reviews the
documentation and produces summary findings detailing any recommendations and
action items.
Cúram Case Audit
Case Audit Administration
1. Specify case types for an audit plan

2. Associate an algorithm with a case audit
configuration
3. Configure focus areas
4. Configure selection queries and criteria
5. Set audit coordinator case
selection permissions
6. Configure case audit security
Notes:
A case audit must be configured before it can be executed. An administrator can configure case
audits for different case types. A case audit configuration must be created for each type of case
audit the organization wishes to use. The maintenance of focus areas, algorithms, and selection
queries is also available within the system administration application.
Selection Query and Criteria

A selection query is used to generate a random sample of cases and contains the selection
criteria that are used to produce the random list of cases. Two types of selection query may be
used, namely, fixed or dynamic. A dynamic query offers flexibility by allowing the audit
coordinator to enter selection criteria, such as case status and a case start date range, which are
then used to produce a list of cases. A fixed query provides a predefined set of selection criteria.
If a fixed query is used to generate a random sample of cases within an audit plan, no audit-
coordinator entry of selection criteria is required.
Audit Algorithm
An audit algorithm is the method or function run by the system in order to generate a random
sample of cases based on the selection criteria specified by the user. A sample algorithm has
been provided. It uses a starting point and an interval to determine the list of cases to be included
in the case audit. An organization may also define their own algorithms to be used for the audit of
different types of cases as necessary.
Focus Areas
Focus areas are the aspects or specific areas of a case that are to be examined by an auditor
when carrying out an audit. The focus areas that are available to be examined during a case audit
are specified within the administration application for the type of case audit that is being
Cúram Case Audit
conducted. The audit coordinator may then select as many of these as are appropriate for the
specific audit being conducted when creating the audit plan. When completing a case audit and
evaluating a particular case, an auditor must then address the focus areas selected.
Cúram Case Audit
Specify Case Types for an Audit Plan
• The following Cúram cases can be audited:

– Integrated - Investigation
– Product delivery - Screening
• Case audits can be conducted on specific case

types, for example, a product delivery case of type
Employment Benefit
Notes:
Cúram Case Audit
Associate an Algorithm with a Case Audit
• An audit algorithm is the method or function run by

the system in order to produce a random sample of
cases based on selection criteria specified by the
audit coordinator
• A sample algorithm has been provided with Cúram
OOTB (Systematic Sampling)
• An organization may also define their own

algorithms
Notes:
Cúram ships with a sample algorithm that uses a starting point and interval to determine the list of
cases to be included in the case audit.
This will select every nth case starting with x, taking into account the number of cases that need
to be audited and the available case load.
Either the audit coordinator enters these values when producing the list of cases, or if not
entered, the system calculates the interval and selects a random starting point.
An organization may also define its own algorithms to be used for the audit of different case
types. This is a customization point that involves development.
Cúram Case Audit
Configure Focus Areas
• An administrator can specify which focus areas will

be available for selection when creating an audit
plan of a particular case type
- New focus
areas can also
be configured
Notes:
Cúram Case Audit
Configure Selection Queries and Criteria
• A selection query must be identified for the case

audit
• This selection query generates a random sample of
cases
– Two types of selection queries exist...
1. ) Dynamic Queries
2.) Fixed Queries
• An audit coordinator has the option to choose which

type of query to use when generating the random list
of cases for audit
Notes:
A selection query must be identified for the case audit. This selection query generates a random
sample of cases and contains the selection criteria that are used to search for and produce the
list of cases.
A dynamic query offers flexibility by allowing the audit coordinator to enter selection criteria, such
as case status and a case start date range, which are then used to produce a list of cases. A
fixed query provides a predefined set of selection criteria. If a fixed query is used to generate a
random sample of cases within an audit plan, no audit-coordinator entry of selection criteria is
required.
Cúram Case Audit
Set Case Selection Permissions
• For each case audit configuration, an administrator

specifies whether the audit coordinator can manually
identify individual cases to be audited
Notes:
Cúram Case Audit
Configure Case Audit Security
• Administrator can specify that a security identifier is

required by the audit coordinator to create an audit
plan
• Restrictions
– Cannot create an audit plan outside of their business area
– Cannot reassign audit plan to another audit coordinator who is
not authorized
– Details can be viewed and modified only by the assigned auditor
or audit coordinator
Notes:
For each case audit configuration, an administrator can specify that a security identifier is
required by the audit coordinator to create an audit plan for the case type being configured. This
ensures that an audit coordinator cannot create an audit plan outside of their business area. An
audit coordinator will also be prevented from reassigning the audit plan to another audit
coordinator who is not authorized for the type of case being audited. Audit-level security also
ensures that case audit details can only be viewed and modified by the auditor, or audit
coordinator assigned to perform the case audit. This ensures that case audits can only be
assigned to auditors, or audit coordinators within their business area. Location-based security
restrictions will still stipulate whether the auditor, or audit coordinator can maintain the case.
Cúram Case Audit
Roles in a Case Audit
Audit Coordinator
• Responsible for the
management and maintenance
of the audit process
Auditor
• Responsible for examining and
evaluating particular case
records to which they have been
assigned
Notes:
Cúram Case Audit
Audit Coordinator Responsibilities
1. Create the audit plan

a. Schedule the audit
b. Select focus areas
c. Produce a list of cases to be audited
d. Assign cases to auditor/audit team
2. View and maintain audit progress
3. Enter summary findings
4. Complete the plan
Notes:
An audit coordinator is responsible for the management and maintenance of the audit process.
They may also contribute to the individual audit of cases. An audit coordinator creates an audit
plan that includes the purpose of the audit, the main focus areas, and the schedule. The audit
coordinator also produces a list of cases to be audited, assigns the cases for audit, and provides
summary findings for the audit plan as a whole. Audit coordinators can view case information for
the cases being audited within an audit plan that they have created, as well as for any case audits
that they may have been assigned to audit individually. Each audit coordinator is only able to
create an audit plan for the types of case that fall within their business function. For example, an
audit coordinator may be able to create an audit plan to audit case types that fall within the Child
Welfare program area, but not the Income Support program area.
Cúram Case Audit
Creating an Audit Plan
• The audit coordinator is responsible for creating the

audit plan
• The audit coordinator must specify the...
1. Type of case that will be audited
2. Purpose for the audit
3. Priority
4. Focus areas
5. Level of user involvement
Notes:
An audit plan manages the details of the case audit process from its inception through to
completion. When creating an audit plan, the audit coordinator must specify what type of case will
be audited, for example, child services investigation cases. The types of case available for audit
must be configured within the administration application before an audit plan may be created.
Along with identifying the type of case that will be audited, the following items of information are
specified: the purpose of the audit, such as a quality assurance review; the priority; the focus
areas; and the level of user involvement. The level of user involvement determines the level of
interaction that the case owner and supervisor will have with the audit being conducted on their
case. The levels of involvement include: Provide Feedback, Provide Feedback When Focus Area
Not Satisfied, View Findings Only, and No Access To Audit Information.
Before auditors can be assigned cases to audit, the audit plan must be scheduled and a random
list of cases generated for the audit plan. Alternatively, the audit coordinator can manually add
cases to an audit plan if the type of case has been configured to allow this in the administration
application. The audit coordinator then assigns the cases identified for audit so that auditors may
begin the process of conducting an audit.
Cúram Case Audit
Audit Coordinator Home Page
• Audit coordinators can configure the type of

information they want displayed on their home page
My Audit Plans
My Case Audits
Case Audit Summary

Audit Plan Summary
Notes:
The following is a list of items that are available for selection on the audit coordinator home page:
Quick Links – Contains the popular actions that an audit coordinator can quickly access,
for example, create an audit plan.
My Appointments – A view of the audit coordinator‟s scheduled appointments.
Available Tasks – Lists tasks available to the audit coordinator, with the ability to filter
tasks by priority and due date.
My Items of Interest – Lists the most recently tagged Items of Interest (cases) that an
audit coordinator has bookmarked.
My Audit Plans – Lists any audit plans for the audit coordinator.
My Case Audits – Lists any case audits that have been assigned to the audit coordinator.
Audit Plan Summary – Graphical display of the status of any audit plans for the audit
coordinator.
Case Audit Summary – Graphical display of the status of any case audits that have been
assigned to the audit coordinator.
Cúram Case Audit
Audit Plan Screen
Notes:
The audit plan screen provides the audit coordinator all the necessary tools to create and
manage an audit plan. This screen contains additional tabs including Home, Case Audits,
Auditors, Focus Areas, Factor History, Selection Criteria, and Transaction History. The audit
coordinator can also view the progress of the audit plan using various graphs.
Cúram Case Audit
Auditor Responsibilities
1. Examine and evaluate assigned cases

2. Address focus areas
3. Provide summary findings on their
individual case audits
4. Review any feedback received from
caseworkers and supervisors
5. Mark audit “complete”
Notes:
An auditor is responsible for examining and evaluating particular case records to which they have
been assigned. They are responsible for providing summary findings on their individual case
audits and reviewing any feedback received from caseworkers and supervisors. Auditors can
view case information for cases to which they have been assigned.
Auditors can only be assigned to audit the types of case that fall within their business area. For
example, Child Welfare cases that require an audit can only be assigned to an auditor who works
within the Child Welfare program area.
Cúram Case Audit
Auditor Home Page
• Auditors can configure the type of information they

want displayed on their home page
My Case Audits
Available Tasks
My Items of Interest
Case Audit Summary
Notes:
The following is a list of items that are available for selection on the auditor home page:
Quick Links – Contains the popular actions that an auditor can quickly access, for
example, case audit search.
My Appointments – A view of the auditor‟s scheduled appointments.
Available Tasks – Lists tasks available to the auditor, with the ability to filter tasks by
priority and due date.
My Items of Interest – Lists the most recently tagged Items of Interest (cases) that an
audit coordinator has bookmarked.
My Case Audits – Lists any case audits that have been assigned to the auditor.
Case Audit Summary – Graphical display of the status of any case audits that have been
assigned to the auditor.
Cúram Case Audit
Audit Team
• One or more auditors responsible for jointly

examining and evaluating particular case records
• Audits can be assigned to an audit team or to an
individual auditor
Notes:
Cúram Case Audit
Summary

– Overview of the case audit process
– Roles and responsibilities in a case audit
– Case audit configuration
– Creation of an audit plan
– Life cycle of a case audit
Notes:
Cúram Rules
10. Cúram Rules
Cúram Rules
Cúram Rules
Lesson Objectives

– identify the two types of rule framework used in Cúram
– describe the Cúram rules definition process
– provide a high-level overview of the rules maintenance and
execution process
Notes:
Cúram Rules
Rules and Evidence
• Rules are the conditions that lead to a decision or

determination, usually dealing with eligibility and
entitlement
• These conditions are drawn from:
– Legislation
– Business policy
• Evidence is the client data/information on which a
decision is based
– You define the data or evidence elements required to validate
each rule
• Cúram uses two types rule frameworks:
– Cúram Express Rules (CER)
– Classic Rules
Notes:
Eligibility and entitlement rules can come from anywhere. Any rule that has a material effect on
the outcome of a case needs to be analyzed and recorded. Some are obvious, such as those
included in legislation, policy guidelines, or stated organizational practice. However, others are
not obvious and need to be established via requirements gathering. It may be obvious to a human
that a client should be alive to claim a benefit. However, this is just another condition and piece of
data to a machine. Evidence is data that you need to record as proof of eligibility or ineligibility.
Evidence must be valid and current.
Cúram Rules
Rules Definition Process
1. Define the rules Business Team
2. Design and develop the rules Technical Team

elements and structure
3. Input and maintain the rules in the Business/Technical Team

Rules Editor
4. Test and validate the rules Business/Test Team
Notes:
When designing and implementing the Rules, Cúram recommends the steps outlined on the
slide. The various teams responsible for each step are also listed above.
Note: The team assignments provided here are only rough guidelines. Frequently, business and
technical staff work together on most phases of the process.
Cúram Rules
Cúram Express Rules (CER)
• CER is a rules language aimed at providing a clear

expression of business rules
• CER rules are used by for several purposes, for
example
– Screening
– Determination
– Display
– Validation
• With CER, reassessment of cases occurs
automatically when any data affecting client
eligibility changes
Notes:
As part of defining CER rules, agencies can configure categories of rules that determine how
eligibility results are displayed. Agencies can also configure explanations of eligibility results that
aid caseworkers‟ and clients‟ understanding of eligibility and entitlement decisions made by the
system.
Cúram Rules
CER Rule Types
• Advisor Rules
– The Advisor infrastructure is part of the CEF
– It uses CER to determine the advice and advice text (context-
sensitive) to display to the user
• Determination or Eligibility Rules
– Determine the eligibility of an applicant
• Display Rules
– Used to display the decisions of eligibility determination to a
user, such as
• Breakdown
• Periods where eligible and entitlement
• Validation Rules
– Used by Dynamic UIM to validate evidence records
Notes:
Cúram Rules
CER Terminology
Rule Class A type of thing that has data, such as a

Person, an Income, or a Claim.
Rule Object An instance of a Rule Class.
Rule Attribute A question that can be asked. It is defined on a Rule

Class and may be asked of any Rule Object of that
class.
Expression A calculation step that can be used to answer a

question.
Rule Set A collection of rule classes, typically centered

around a specific purpose.
Rule Session Controls the running of rules.
Notes:
Examples of the CER Terminology
Rule Class – A Person, an Income, a Claim.

Rule Object: John Smith (a Person); John Smith's income from his part-time job
(Income); or John Smith's application for child support benefits (Claim).
Rule Attribute – The Person rule class may define the dateOfBirth rule attribute. So the
John Smith rule object may be asked its dateOfBirth, for example, October 3, 1970.
Expression – If the eligibility of a claim depends on a person's total income being below a
certain threshold, we can use a "sum" expression to calculate the total income and then
use a "compare" expression to compare that total with the threshold amount. To create
an expression, a "sum" rule element can be dragged to the rule attribute in the CER
Editor.
Rule Set – A rule set for child benefit determination might include the rule classes Claim,
Person, and Income.
Rule Session – Your application might create a rule session to determine John Smith's
eligibility for child benefit. The application invokes the appropriate rule set and asks
eligibility questions regarding John's personal circumstances.
Cúram Rules
CER Categories
• Categories are used to make it easier to find CER rules

• Can create own categories in the Administration tool
Notes:
Cúram Rules
CER Editor
• A Flex-based editor used to create, edit, and validate

CER rule sets
– Part of the administration application
– Diagrammatic representation of rule sets
– User-friendly for business users
• Drag and drop of elements for ease of use
– Element properties can be easily modified
– Uses pop-up menus and wizards
• Contains search tools
– General search and reference search
• Has business and technical views
Notes:
The CER editor enables business users to create and edit the logical structure of their rules using
diagrams that provide a logical view of the underlying rules implementation. The user can edit
rules logic by dragging items from a palette of available elements on to the appropriate place in a
diagram. Dialogs and wizards can be used to fill in any extra information required.
Technical users can also use the editor to add extra information required to complete the rule set
definition in a way which doesn't alter the logical view of the rules. This makes it easy for both
business and technical users to understand and maintain the rules it contains.
Cúram Rules
Notes:
Cúram Rules
CER Elements
Notes:
Element palettes can be un-docked by dragging the palette from the original position on to the
diagram canvas, which makes them easier to view.
Cúram Rules
Classic Rules Framework
• The Classic Rules Framework supports the definition

and maintenance of rules and their execution against
gathered evidence
• Framework consists of the following components:
– Rules Editor
– Rules Engine
– Rules Simulation Environment
• These components enable you to define, maintain,
and execute rules over time
• Retroactive evidence changes are allowed and
accomplished via effective-dated rate tables and rule
sets
Notes:
Cúram provides a tool called the Rules Simulation Environment, which works with the Rules
Editor to test the suitability of rule sets before development builds them into the application.
Cúram Rules
Use of Classic Rules in Cúram
• Cúram uses classic rules in two ways:

– Eligibility and entitlement
• Is the client eligible for something?
• What and how much is the client entitled to?
– Work allocation
• Determines how tasks are allocated in the organization
• Based on a work allocation strategy
Notes:
Cúram Rules
Classic Rule Set
• A classic rule set consists of two basic

components:
1. Rules implemented using rule groups, rule list groups, and rules
2. Objectives implemented using objective groups, objective list
groups, objectives, and objective tags
• Classic rule sets are defined in a tree structure
• Each eligibility rule set must have at least
1. One main rule group
2. One main objective group
• These two main structures contain the rest of the
structural elements of the rule set
– Examples: Rules, objectives, objective tags, rule list groups,
and so on
Notes:
A tree must have one root element. In this case, this root element is the rule set. From here, we
can have two branches represented by the rule group and the objective group. This might
suggest that all rules are contained within one group and the objectives within the other, but this
is not the case. The rule group at this level acts as a set of prerequisites that must pass before
any other rules or objectives can be evaluated. The objective group can also contain other rule
groups and rules, so the tree can expand to match your requirements.
Cúram Rules
Rule Groups
Notes:
The purpose of rule groups is to group one or more rules and rule groups using logical AND or
OR operators. Rule groups can contain the following components:
Rules – One or more conditions using logical OR or logical AND operators

Data item assignment variables for rules, for example, age
Other rule groups
Rule list groups – Similar to rule groups except that they execute the rules using an array
of data
Sub-rule set links
The root rule group contains the prerequisite rules to establish eligibility. Once this has been
established, the claimant is entitled to something. The exact entitlement depends on the
objectives, each with its own rules. More complex rule sets have many levels of conditions that a
client has to pass to be eligible and receive any entitlement.
Cúram Rules
Objectives
• Objectives are the outcomes of passing eligibility

• An objective can be one of the following types:
– Money
– Product Delivery
– Assessment
– Double
• You can award objectives to different participants,
for example, service supplier, employer, or person
• Each objective has one or more tags
• Objective tags define the following:
– Value or formula of an objective
– Frequency at which the objective tag applies
Notes:
An objective is a post-assessment outcome or entitlement.
Money – Represents a debit or credit component awarded as a result of successful

completion of eligibility assessment.
Product Delivery – Client to receive a benefit or liability.
Assessment – Client is recommended for another assessment.
Double – Assessment results in a double, a numeric value.
The objective tag specifies the rate to be paid by the organization, or the amount owed to the
organization. The objective tag is used to create the financial component generated from most
case decisions. An objective tag is an amount of money for a specific objective. An objective tag
is defined in terms of a specific period of time, which means that an objective may have several
objective tags. For example, an unemployment benefit product may have two objective tags, one
for “per day” and one for “per week.” An objective tag may also contain a recommendation for
another product or assessment.
Cúram Rules
Objective Groups
• Logical group of product or assessment objectives

• Each group has an associated conjunction, which
governs how objectives are combined at runtime
– All objectives
– Highest value
– First objective
– Highest priority
• An objective group can contain
– Objectives
– Other objective groups
– Objective list groups
– Rule groups
– Rule list groups
– Sub-rule set links
Notes:
The objective group acts as a container for objectives, or other objective groups. Depending on
policy, it may be decided at this level that all successful objectives should be awarded, or that
only one can be awarded. Where only one objective can be awarded, it can be decided based on
priority or value. For example, the Rules Engine might assess each and then award the highest
priority objective. This would apply in cases of emergency assistance need.
Every product must have one objective group that acts as the root for all other associated
objective groups and their objectives. For simple products, you may have only one objective to
specify that a benefit should be paid. In reality, products are more complex and usually require a
series of objectives.
Objective types are the leaves of the objective group tree. An objective defines a rate for a given
product condition. Alternatively, an objective defines a product or assessment recommendation.
There may be hundreds of objectives for a product.
Cúram Rules
Sub-rule Set
• A sub-rule set is a reusable subset of rules

• You can define sub-rule sets within the high-level
rule set and call the sub-rule set from different
locations
• This enables you to factor out rules common to
several products or assessments, avoiding
duplication and promoting good rule design
Notes:
A sub-rule set is a reusable subset of rules. A sub-rule set can be called, or linked to, from more
than one place in the main rule set. Sub-rule sets are used where rule structures are similar
across different products, for example, the repayment mechanisms for different loan products.
The use of sub-rule sets involves virtually no runtime overhead. In addition, careful use of sub-
rule sets during design time can increase speed of development and reliability. Sub-rule sets can
be useful when developing large rule sets. It allows multiple developers to work on separate parts
of the rule set without interfering with each other. This can also facilitate source control
management.
Cúram Rules
Rule and Objective List Groups
• Rule List Groups and Objective List Groups are used

to evaluate a set of rules or objectives multiple times
• May be used when assessing multiple members of a
household
Notes:
A rule list group provides the same functionality as a rule group, that is, it allows you to define a
group of rules and the conjunction to be used when executing them. Where it differs is that you
must assign a List RDO (rules data object) to the rule list group. The Rules Data Object (RDO)
models the data that is used by the rule set to do a calculation. The rules within this group are
executed for each element within the List RDO. Rule list groups can be added anywhere a rule
group can be added.
Objective list groups have a similar relationship to objective groups as rule list groups have to rule
groups. You must specify the List RDO associated with the objective list group. The objectives
within this group and any rules contained within them are evaluated for each element within the
List RDO. An objective list group succeeds whenever an objective group for at least one of the
data records in the List RDO succeeds.
Cúram Rules
Classic Rules Editor
• You can use the Classic Rules Editor to create and modify rules
in a running application
• The Classic Rules Editor enables you to maintain the following
components:
– Rule sets - Objectives
– Sub-rule sets - Objective tags
– Rule groups - Objective groups
– Rule list groups - Objective list groups
– Data item assignments
• Rule sets are written in XML, then imported into Cúram
• Rule sets reference evidence and rate table data
• Rule sets can be cloned
• Rule sets are linked and effective-dated to products and
assessments
Notes:
You link a rule set to a product or assessment via the Product (or Assessment) Home Page in the
Administration Manager.
Cúram Rules
Classic Rules Engine
• Infrastructure component
• Executes rules
– On-line
– At regularly scheduled intervals via batch jobs
• Executes the rules in combination with the evidence
to produce a decision
– A decision consists of an indicator specifying whether the
conditions succeeded and whether a list of financial and non-
financial objectives were achieved, or not achieved
• Maintains a record of all decisions for a case
Notes:
Cúram Rules
Business Processes and Evidence
Rule set
Evidence
Objectives Rules
Entities
(Outcomes) (Conditions)
(Tables)
Rules Data Rules Business

Loaders
Object (RDO) Process
Notes:
The Rules Development Architecture allows for loose coupling between the rule set and
evidence. The rule set consists of prerequisite rules and objectives or outcomes. When a rule set
is invoked by the running of a business process, each rule requires certain data before it can be
executed by the Rules Engine. The Rules Data Object (RDO) models the data that is used by the
rule set to do a calculation. The RDO uses a hand-written loader class and business process to
retrieve the data from the evidence entities at runtime. Therefore, a rule is based on a piece of
evidence that is retrieved during the running of the appropriate business process.
Cúram Rules
Summary

– Rules definition process
– Cúram Express Rules
– CER editor
– Classic rules framework
– Rules engine
– Rules processing
Notes:
Cúram Workflow
11. Cúram Workflow
Cúram Workflow
Cúram Workflow
Lesson Objectives

– describe the following components of Cúram Workflow™:
• Process Definition Tool (PDT)
• Workflow Engine
• User Inbox
• Workflow Administration
Notes:
Cúram Workflow
What is Cúram Workflow?
• Cúram Workflow supports the automation of

business processes and allows work to be routed
among individuals and other organizational objects
• Cúram Workflow consists of four components that
can be divided into two areas:
– Workflow Infrastructure
• Process Definition Tool (PDT)
• Workflow Engine
– Workflow Functionality
• User Inbox
• Workflow Administration
Notes:
Process Definition Tool (PDT)
Allows workflow processes to be defined
Activities and rules for routing between activities are created
Manual and Decision activities define the points at which human intervention is required
Workflow Engine
Performs runtime execution of a workflow process instance
Manages the process instance life cycle, executing activity instances and evaluating
transition rules
Creates tasks to notify users that manual work needs to be done and evaluates allocation
rules to determine which users should be notified
Responds to workflow events, such as the completion of a work item, which tell it to
resume the execution of a process instance
User Inbox
Contains notifications and tasks that need to be undertaken
Workflow Administration
Enables an administrator to monitor and control process instances executed by the workflow
engine. Functions include the following:
Process Instance Search
Suspend
Resume
Abort
View Process Instance Errors
Cúram Workflow
Process Definition Tool (PDT)
• You use the PDT to define workflow processes

• A workflow process consists of the following
components:
– Activities
– Transitions
– Workflow Data Objects (WDOs)
• The PDT enables dynamic definition and
modification of workflow processes
Notes:
You use the PDT to create workflow process definitions and to define the data that passes
through a workflow. Workflow process definitions describe the sequence of activities and
transitions that make up a business process workflow. Workflow data objects (WDOs) are used to
define the data that passes through a workflow. The PDT also contains a library for the business
process object (BPO) methods that are available for use by workflow process definitions. The
main function of the PDT is to create workflow process definitions by defining the activities in a
workflow and the transitions between them. There are various activity types to choose from when
creating a process definition. The behavior of these activities is determined by the transitions
between them, the conditions for these transitions, and the data that passes between them.
An activity is a step in the workflow process, that is, a discrete piece of work that must be
completed before a workflow process can progress.
A transition describes the movement of a workflow process between two activities. There are two
important aspects of transitions. The first is how the split and join types for an activity influence
the transitions to and from that activity. The second is the conditions placed on a transition.
Conditions are used by transitions to make a decision on what should happen next in the
workflow process.
Workflow data objects (WDOs) are used to define the data that passes through a workflow. The
data might include such information as case ID, case owner, dates, durations, and amounts.
Cúram Workflow
Workflow Activities
• Workflow activities can be subdivided into the

following types:
– Start
– End
– Manual (creates a task)
– Decision (creates a task)
– Automatic
– Event Wait
– Route
– Sub-flow
– Loop
– Parallel
Notes:
Start and End
All workflow process definitions have a start and an end activity. When a workflow is enacted, the
transitions from the start activity are the first to be evaluated. A workflow is completed when the
transitions to the end activity are evaluated and the end process activity is executed.
Manual
Manual activities are steps in the workflow where a human being must intervene. When a manual
activity is executed a task is created that specifies the work that needs to be done. To select an
appropriate user to work on the task, an allocation strategy is specified for the manual activity. A
task describes the work to be performed and provides links to the pages in the application where
the work can be carried out. A manual activity also specifies an event that will be used to signify
that the work required for the manual activity has been completed. The Workflow Engine waits for
this event to be raised. Once it receives the event, the activity is completed and the workflow
proceeds to the next activity. A deadline strategy may also be specified for a manual activity. This
specifies what should happen if the activity is not completed within a given amount of time.
Decision
A decision activity is an activity that asks a human agent a question. A task is created when a
decision activity is executed. This task contains a generic system-provided action that allows a
user to answer a question. A decision activity supports two types of question: a multiple choice
question provides the user with options to select an answer from, while a free form question
allows the user to enter free form text in order to answer the question.
Cúram Workflow
Automatic
An automatic activity is a step in a workflow process that is wholly automated and under normal
circumstances no human intervention is required for the completion of such a step. An automatic
activity step invokes a method in the application to perform some processing required as part of
the overall business process.
Event Wait
Similar to a manual activity, an event wait activity stops the workflow until a given event is raised.
Unlike a manual activity, a task is not created when an event wait activity is executed. An event
wait activity may also specify a deadline.
Route
A route activity is an activity that performs no business functionality whatsoever. It can be
considered a null activity as its execution does not affect the application data nor the business
process in any way. The primary purpose of the route activity is to assist in flow control. Another
purpose for route activities is to place notifications at particular points in a workflow process.
Sub-flow
A complex business process may become too large to manage as one monolithic process
definition. A sub-flow activity allows another process definition to be enacted as part of another
process.
Loop
A loop is a sequence of activities that continues to execute while some condition is true. All loops
must start with a Loop Begin activity and end with a Loop End activity. Loops can also be nested
within other loops.
Parallel
A parallel activity acts as a wrapper around existing activities. The effect of using one of these
activities at runtime is that multiple instances of the wrapped activity are executed in parallel. To
date, the only supported types of wrapped activity are Manual and Decision activities. Therefore,
executing a parallel activity currently equates to the creation and allocation of multiple tasks in
parallel.
Cúram Workflow
Workflow Engine
• Performs runtime execution of workflow processes

based on process definitions
– The Workflow Engine uses the process definition to create a
Workflow Process Instance
• Evaluates defined transitions and activities to
determine the following:
– Which activities to execute
– The appropriate routes through the workflow
– When tasks are required
– When notifications are required
• Maintains the data relevant for the process instance
throughout the lifetime of the process instance
Notes:
The main responsibility of the Workflow Engine is to enact all workflow processes at runtime. The
Workflow Engine creates a new instance of a workflow process definition each time an event calls
for a new enactment of the workflow, or each time a business process calls for the execution of a
workflow.
The Workflow Engine uses enactment WDOs that have been mapped to a workflow process
definition to enact the new process instances. In addition to enactment WDOs, the Workflow
Engine defines WDOs to store runtime data commonly required by all workflow process
definitions. The Workflow Engine manages the process instance life cycle, executing activity
instances and evaluating transition rules. During the process instance life cycle, the Workflow
Engine continues to respond to events, such as the completion of a task, which tell it to resume
the execution of a process instance. The Workflow Engine creates tasks to notify users when
manual work needs to be done, and evaluates allocation rules to determine which users should
be notified. The Workflow Engine also creates notifications for users to inform them of the
progress or status of a workflow process instance.
The Workflow Engine sees each process instance through to the end. If the workflow process
instance fails, it records information about the failure. This information can then be used to try to
restart the workflow process instance.
Cúram Workflow
Task Creation and Allocation
• Tasks enable the assignment and tracking of the

work of system users
• The Workflow Engine creates tasks to complete
manual and decision activities and assigns these
tasks to a defined allocation target
• An allocation target can be any of the following:
– User
– Position
– Job
– Organization unit
– Work queue
– Combination of any of the above
Notes:
An allocation strategy details how a task created due to the execution of a manual or decision
activity is assigned to a user who will perform the task. Allocation targets can be specified
manually by an administrator via a handcrafted work allocation function (Java), or via a work
allocation rule set. An allocation target will be one of the following: a user, a position, a job, an
organization unit, a work queue, or a named list containing any combination of the
aforementioned. This is because the end result of an allocation strategy is to ensure that the task
is completed by an appropriate user or group of users.
You can create task deadline strategies to ensure that the task is reserved and promptly
completed by a user. Deadline strategies can be configured to deal with any tasks that exceed
defined deadlines. Tasks are divided into three categories, namely, available, open, and deferred.
The list of available tasks includes tasks that have been allocated to a user or multiple users but
not reserved (moved to My Tasks) by one of these allocation targets. Users can reserve any of
their assigned tasks. Once a task is reserved, it is removed from the list of available tasks and
added to the My Open Tasks list. It also becomes part of a user's workspace from where it can be
monitored.
Users are responsible for the completion of their tasks. While in progress, a user can change the
amount of time spent on a task. Users can choose to “make available” a task, thereby making it
available to the original assigned users. Alternatively, they can reallocate the task to make it
available to users based on the most current allocation strategy. They can also forward a task to
a new target, or defer it until a later date. If a user defers a task, it is removed from the list of open
tasks and added to the list of deferred tasks. Deferred tasks can be restarted manually by a user
or automatically by the system. This restores the task to the list of open tasks.
Cúram Workflow
User Inbox
• System users manage tasks from the User Inbox

• The main areas of the Inbox are as follows:
– Tasks
• Available
• Open
• Deferred
– Task queries
– Task preferences
– Work queues
– Notifications (Alerts)
• Notifications can also be delivered as e-mails
Notes:
Tasks – The work or potential work that is assigned to a user. A task is either available, open, or
deferred.
Task queries – Users can create their own queries to search/filter the tasks in their inbox. The
queries can be saved so they can be run as needed.
Task preferences – Task redirection and blocking can be set up, as well as the user‟s preferred
work queue or organization unit.
Work queues – Work queues are allocation targets to which users can subscribe. Users can
reserve the next task in one of their work queues. Alternatively, they can allow the system to
determine the next task to be reserved. The system searches for tasks assigned to the user's
work queue that are high priority and approaching their deadline.
Notifications – Contain information that may be of interest to a user. They differ from tasks in that
there is no required action for the user to perform. Therefore, there is no action or work to be
managed by a supervisor. Notifications can be issued to a user as an alert (internal to Cúram) or
e-mail (external to Cúram). Alert notifications display in a user's list of notifications until deleted by
the user.
Cúram Workflow
Tasks
• Task screen
– Subject text
– Deadline
– Primary action
– Supporting information
– History and comments
Notes:
The task history is a record of all the events that have occurred during the life cycle of a particular
task. Each time an event occurs, the task history is updated with the name of the user
responsible for the event, the date and time the event occurred, the value before the event that
has changed, and the new value. Task events are as follows:
• Task Created
• Comment Added
• Time Worked Changed
• Priority Changed
• Deadline Changed
• Added to My Tasks
• Made Available
• Forwarded
• Allocation Failed
• Allocated To Default Queue
• Reallocated
• Deferred
• Restarted
• Deadline Expired
• Closed
Cúram Workflow
Workflow Administration
• Enables an administrator to monitor and control

workflow process instances
• Functions include the following:
– Process Instance Search
– View Process Instance Errors
– Suspend, Resume, Abort (the process instance)
– Events
Notes:
The Workflow Administration application monitors and maintains workflow process instances,
process instance errors, and workflow events.
Process Instance Search

The Process Instance Search function allows an administrator to search for a specific process
instance among the currently executing process instances, or those that have already completed.
There are several options available for such searches. Search By Process Details allows an
administrator to search for process instances using the „process enacted from‟ and „process
enacted to‟ date range, the „process completed from‟ and „process completed to‟ date range, the
process name, the process instance identifier, and the status of the process. Any combination of
the search criteria outlined above may be used in this search. Search By Task Details allows an
administrator to search for currently executing process instances by associated task identifier,
tasks reserved by a specified user, tasks associated with a case, or tasks associated with a
participant. Search By Event Wait Details allows an administrator to search for currently running
process instances that contain activity instances waiting on the specific event used in the search
criteria.
View Process Instance Errors

Any errors encountered by the workflow engine during the execution of a process instance are
displayed in the process instance error list. The administrator can choose to abort or retry the
associated process instance.
Suspend – This function allows the administrator to suspend an in-progress process

instance. The process instance must be restarted before any further activities will be
invoked.
Cúram Workflow
Resume – This function is used to restart a suspended process instance.
Abort – This function is used to terminate an in-progress process instance. Once aborted,
a process instance may not be restarted.
Events
Events are used to transition workflows, or to enact process instances of workflows. Manual and
event wait activities will use events to progress a process instance. The application raises an
event when the action associated with a manual activity (task) is complete, or when a particular
event defined for an event wait activity has been completed. These events signal the Workflow
Engine to progress the process instance. The application will also use events to enact a workflow.
When an action associated with an enactment event occurs in the application, the Workflow
Engine reads this event and starts a new process instance of the workflow.
Cúram Workflow
Summary

– Process Definition Tool (PDT)
– Workflow Engine
– User Inbox
– Workflow Administration
Notes:
Cúram Documentation Center
12. Cúram Documentation Center
Cúram Documentation
Center
Lesson Objectives

– describe the structure of the Cúram Documentation Center™
– use the following tools to learn more about the Cúram
application:
• Business Guides
• Process Flows
• Reference Models
Notes:
• Repository for key Cúram documentation

– Release notes
– Process flows
– Reference models
– Business guides
– Installation guides
– Ability to search the guides
• Headings only
• Full-text
• Designed for the implementation and support teams,

not the end-user
Notes:
The search functionality in the Documentation Center searches only the PDF guides, not the
process flows and reference models, which are graphics files. Searching the guides is a two-step
process. The first search returns a list of guides containing the word or phrase for which you are
searching. After selecting the guide you want to review, you must then search for the word or
phrase within that guide.
Structure
• Business Analysts
– Process flows
– Reference models
– CIARA
– Business guides
• Developers
– Development
– Getting started
– Deployment
• Administrators
– Guides
• Component filter to include or exclude certain

modules from display
Notes:
Each section of the Documentation Center contains information for a specific type of user. For
example, the Business Analysts section contains guides that a business analyst might use to
understand the application. The Developers section focuses on the architecture of Cúram, Cúram
installation, third-party tool installation, and configuration guides. These contain information about
the supported operating system platforms and details of supported hardware and software.
Detailed developer guides and reference manuals are provided, which cover a range of topics,
such as rules development, workflow management, server modeling, XML infrastructure, and
Cúram case and financials. It also provides detailed documentation about the deployment of
Cúram and related third-party products. The Administrator section focuses on third-party tools,
installation, and deployment guides.
The Documentation Center includes access to the process flows that are contained within Cúram.
It also contains reference models that you can navigate. From all reference model diagrams, you
can drill down to the entity and attribute descriptions. You also have access to the Cúram Impact
and Relationship Analyzer (CIARA). CIARA is included in the Documentation Center, but is also a
stand-alone tool. It provides summary information about the Cúram design, including design
objects and relationships between them.
Reference Models
• Entity relationship diagrams (ERD) for all Cúram
components, including core and infrastructure
• Provides a logical representation of the Cúram physical
data model
• Contains descriptions of all entities and attributes
Notes:
The reference model is a logical entity model for the Cúram reference application. It is presented
graphically and depicts the core data objects where the reference application is implemented. It
represents all the logical entities that make up the Cúram data model. The reference model
diagrams use standard entity relationship diagram (ERD) notations to illustrate relationships
between entities. Various hyperlinks incorporated in the diagrams provide single-click access to
detailed descriptions of the attributes associated with each entity.
Process Flows
• Visual representation of business processes that are

implemented in Cúram
• Maintained in Microsoft Visio™ documents that are
generated into HTML
• Provides links to the following:
– Cúram reference model entities
– CIARA
– Other process flows
– Screen previews
– Guides
Notes:
Process flows depict the functional capabilities implemented in Cúram. The business process
flows provide a description of the features implemented in Cúram. Process flows are presented
graphically in diagrams with textual descriptions. The diagram also contains hyperlinks that
provide single-click access to other relevant areas of documentation. The process flows are
grouped into categories, such as Case, Financial, and Participant. This enables you to search for
information about a specific category more quickly. As you drill down to a specific category, you
are provided with a visual display of the business activities. You can then see an overview of the
business process, including validation information, or specific BPO method and implementation
information.
Benefits of Cúram Process Flows
• Starting point for requirements definition

• Enables you to examine differences between out-of-
the-box processes and new requirements
• Focuses design on what Cúram already provides
• Helps to focus on reusing, rather than reinventing
Notes:
The process flows enables you to see what Cúram provides out-of-the-box. Therefore, you can
use process flows as the starting point during requirements definition for a specific
implementation. By starting with the relevant process flow, business analysts and subject matter
experts can determine whether it meets their relevant business process. They can also document
and highlight the gaps that were identified.
Process Flow Key
Notes:
When viewing a process flow, you can click the shapes to uncover more information about the
process.
Summary

– The structure of the Cúram Documentation Center
– Using the primary tools within Cúram Documentation Center:
• Business Guides
• Process Flows
• Reference Models
Notes:
CIARA
13. CIARA
CIARA
CIARA
Lesson Objectives

– describe the Cúram Impact and Relationship Analyzer™
(CIARA) tool and Cúram design objects
– navigate the Cúram Documentation Center™ version and
standalone version of CIARA
Notes:
CIARA
What is CIARA?
• Proprietary impact analysis tool for Cúram

• Contains summary information about the design and
structure of Cúram
• Displays design objects and their relationships in a
tree structure
• Used to analyze the impact of a change to the
existing application
• Two versions of CIARA
– Documentation Center
– Standalone
Notes:
The Cúram Impact and Relationship Analyzer (CIARA, pronounced [KEER-ah]) is a tool that
provides summary information about the design and structure of Cúram. It provides access to
design objects, that is, screens, database tables, fields, and business process objects (BPOs). It
displays these objects and their interrelationships in a tree structure. CIARA enables users to drill
down through these trees to obtain more detailed information about the specific objects. It allows
users to explore the relationship between design objects. You can use CIARA to assess the
impact of a change or to see what objects are used in screens and processes.
CIARA is available in the Cúram Documentation Center™ and as a standalone tool. Each version
has a different look and feel, but both work on the same principle. Standalone CIARA contains
the following advanced features:
Viewing object properties

Executing queries
Launching objects
Setting tree style
Reloading the database
Compacting the database
Comparing two databases
CIARA
CIARA Design Objects
• Examples of design objects

– Database tables
– Code tables
– Rule sets
– User interface files (screens)
– Error messages
• Examples of relationships
– Process method calls an operation on a database table
– Message catalog contains messages
– Source code file method calls a method in another source file
Notes:
CIARA displays lists of design objects based on search criteria or by selecting a specific object
from the database. It also displays the relationship of the selected design object to other objects.
Typical path through the relationship is as follows:
Entity (database table) contains operations, such as insert and read

Process method may use these operations to manipulate the database
Process method may be called by other process methods as part of completing a specific
task
Process flow may reference a process method to describe what must occur for this task
to complete successfully
Example: The Person entity has an „insert‟ operation that is called by a process method
PersonRegistration.registerPerson. This method is referenced by the Register Person process
flow. In this process method (registerPerson), there are calls to operations on other entities, such
as Concern and ConcernRoleAddress.
CIARA
Documentation Center CIARA
Notes:
When Documentation Center CIARA is launched, the initial screen shows the different types of
design objects. You can browse to a particular type of object, or search for an object. If you
already know the name of the object and its type, you can enter the object name in the search
field. However, if you are exploring the Cúram design database to see if certain features exist,
you may want to search through a group of design objects.
The search facility in CIARA is a way to navigate to specific information within the CIARA
repository. By selecting the design object type, the user can minimize the criteria for the search
and reduce the time taken to find the required design object. If the type is unknown, there is the
All Types option, which provides the widest search.
CIARA
Design Object
Notes:
In this example, the TECH method has the following relationships and information:
CALLED BY SOURCE – The other class methods that call this method
IMPLEMENTED IN FILE – The files that implement this class and the location of the
class (core.AdminBank.java)
IMPLEMENTS BPO METHOD – Links to the summary information
METHOD ON – Indicates the class this method is on
HAS PARAMETER – Shows the argument structs for the method
USES – Shows all other relationships between this method and the following:
Messages
Code table items
Other class methods
CIARA
Standalone CIARA
• Installed as a separate application

• Displays in a tree structure in a new window
• Launches objects using CIARA viewer plug-ins
• Includes more advanced features than
Documentation Center version, including:
– Reloading and creating the repository
– Comparing two CIARA databases
• View the object properties for more information,
such as description, relationship type, and source
• Search for a specific CIARA object name or use a
wildcard
– ? = single character
– * = multiple characters
Notes:
There is a standalone version of CIARA that allows you to view the design repository, which is
held in a Microsoft® Access database. This version of CIARA has all the features of the
Documentation Center version and some more advanced features. The standalone version can
launch in a separate window and display information in a tree-type view.
An advanced feature of the standalone version of CIARA is the ability to take you to the source of
the design object. You can launch an object using one of the following CIARA viewer plug-ins:
Rose Model – For design objects sourced from the Rose model
HTML – For any XML or HTML files
Text – For design objects sourced from text files
Microsoft® Visio – For all process flows
Before launching an object, you must specify the launcher and the source must exist on the
computer. At installation, CIARA defaults to using Notepad as its text editor. However, you can
set your own text editor. For CIARA to launch the design object, the source for that object must
exist on the same computer.
CIARA
Standalone CIARA
D1
Notes:
Standalone CIARA displays its contents in a tree view. It also displays the number of items within
each node. For example, in the version of CIARA shown above, there is information about 1719
code tables and 1255 database tables. The ConcernRole database table contains 25 columns
(also known as “attributes”).
CIARA
Comparing CIARA Databases
• Use the CIARA Viewer and the RunCIARAComparer

command to compare two databases
• Export the comparison data for each database
before running the tool
• Possible to use the output as the source data for a
new database
Notes:
To compare two repositories, you must export the data from each of these databases. You can
compare the data by running the external tool RunCIARAComparer, which uses the older and
newer comparison files as arguments.
You can compare two CIARA databases to see the updates and modifications. You compare
databases to identify or locate the following:
Objects that have been added or deleted in the newer database

Objects that have been removed
Objects that are present in both databases, but differ in some way
Objects that are present in both databases, but whose set of related objects differs
between the databases
Objects that are identical in both databases
Relationships that have been added to the newer database or removed from the older
database
Identical relationships in both databases
CIARA
CIARA as a Gap Analysis Tool
• Use CIARA to drill down for more information about

an object
• Determine whether Cúram has specific functionality,
for example, Register a Person
• Starting point depends on the information that you
have and your goal, for example:
– Check whether certain features exist in Cúram
– Assess the impact of a change to a specific screen
– Analyze relationships between different design objects
Notes:
You can use CIARA as a gap analysis tool to see if a feature exists or partially exists within the
framework. Because CIARA allows you to drill down, you can see how a design object is
constructed. You can also select the design object to view its relationships. For example, you
may want to view the Register Person features to see which design objects are implemented. If
you are dealing with a Person entity and the Register operation, you may want to view the Entity
Table design object. Although the design object names may not match Person and Register
exactly, you can assume that you are looking in the correct area.
CIARA
Summary

– Design objects
– Navigating and using CIARA
– Differences between Doc Center CIARA and standalone CIARA
Notes:
Cúram Certification Program Overview
14. Cúram Certification Program Overview
Cúram Certification
Program Overview
Introduction
• Cúram Software offers two certification programs

– Cúram Certified Professional (CCP)
– Cúram Certified Developer (CCD)
• Each certification exam is designed to verify that a
candidate has the core skills required to work
effectively as a business analyst or developer on a
Cúram project implementation team
Notes:
By taking this business analyst course, you are eligible to take the CCP exam. If you wish to
pursue the CCD certification, you must first take the developer course.
Exam Structure
• Exam contains 40 multiple-choice questions

• Exam duration is one hour
• Two question types
• Single-answer: For example, select one option (Typically from four)
• Multiple-answer: For example, select more than one option
• Passing score = 70% (28 correct out of 40)

• No negative marking
• Closed-book exam
Notes:
For all multiple-answer questions, the phrase “Choose more than one option” will appear at the
end of the question text. You will not be told exactly how many answers are correct, but you will
know that you should choose two or more options. For single-answer questions, the phrase
“Choose one option” will appear at the end of the question text. Also, the testing interface will
prevent you from selecting more than one option.
You will take a short practice test at the Prometric testing site. The purpose of the practice test is
to familiarize you with the Prometric testing interface, enabling you to practice navigating through
the Prometric system. This practice exam does not contain Cúram certification questions. A set of
sample certification questions is contained in the training manual.
Domains and Topics

• Cúram Enterprise Framework = 45% (18 questions)
– Administration
– Case
– Case Audit
– Participant
– Temporal Evidence
• Business Infrastructure = 35% (14 questions)

– CBAS Structure and Components
– CIARA
– Documentation Center
– Rules
– User Interface
– Workflow
• Enterprise Modules = 20% (8 questions)

– Financials
– Outcome Management
Notes:
This list presents the three main areas (domains) that are covered by the CCP exam, namely,
Cúram Enterprise Framework, Business Infrastructure, and Cúram Enterprise Modules. The list
presents the question distribution for each exam area and the topics contained within each area.
Exam Preparation
• All of the possible exam questions come from

content in the main training manual for CB600 –
Fundamentals of the Cúram Enterprise Framework
(V6) for Business Analysts
• In addition to studying the course manual, it is
strongly recommended that you study the questions
in the exercise workbook
Notes:
The amount of preparation time required for the CCP exam will differ for each candidate. Each
person will have their own study techniques, which will vary in terms of the amount of time they
take to complete and the precise set of study activities. In addition, the amount of experience that
a candidate has will also have an impact on the amount of preparation time they require. More
experienced candidates may require less preparation time than less experienced candidates. In
these circumstances, it is inadvisable for Cúram Global Learning Services (GLS) to provide hard
and fast guidelines as to the precise amount of time that a candidate should set aside for exam
preparation. However, it is possible for GLS to provide general exam preparation guidance that
each candidate can adapt to their individual learning requirements, study techniques, and
professional background.
GLS recommends that CCP candidates take the exam within 4-8 weeks of completing CB600 –
Fundamentals of the Cúram Enterprise Framework (V6) for Business Analysts. GLS recommends
that candidates spend approximately 6 hours a week preparing for the CCP exam over a period
of 4-8 weeks. Candidates should note that these figures are guidelines only and do not constitute
a guarantee that CCP certification will be achieved if the recommended weekly study allocation
and overall study period are undertaken by the candidate. The amount of study time per week
and the length of the overall study period must be adjusted to the individual circumstances of the
candidate.
Exam Policies
• Attending the business analyst training course (CB600)

entitles all students to one free exam attempt if the exam is
taken within 90 days of the completion of the training
course
• There is a charge of $150 USD (or local equivalent) for each
exam re-sit and attempts outside of the 90-day window
• Beyond the 90-day window, the CCP exam must be taken
within one year from the course end date, or candidates
must re-sit the course or apply for a waiver (providing
waiver reasons) before they may attempt the exam for the
first time
• Candidates may attempt the CCP exam three times (1st
attempt plus 2 retakes) for any given release within 1 year
of course dates
Notes:
Exam Policies
• If a fourth attempt is required, written permission

must be obtained from Cúram Software
• If an exam is scheduled and not taken, this is
deemed to be an attempt
• If a certification exam is not successfully completed
on the first attempt, there is no required wait before
making a second attempt
• A minimum period of twenty (20) business days
must elapse between the date of a candidate’s
second attempt and their planned third attempt at
the test
Notes:
Post-Certification Training
• Cúram eLearning Passport™
– Web-based training (WBT) portal
– 24/7/365 availability, allowing learners to access targeted Cúram
training whenever and wherever they need it
– Comprehensive library of lessons that provides broad and deep
coverage of CBAS modules and framework components
– Continuity coverage of Cúram product versions – eLearning
Passport contains WBT that spans versions of Cúram from V4.0
to V6
– Lessons include self-review questions that test a learner‟s grasp
of the topic being covered
– Access to new courses and updates
– Upgrade courses that keep you informed of product changes,
providing a convenient and cost-effective way to upgrade your
certification status when a new version of Cúram is released
– Regular e-mail updates when new content is added
Notes:
The Cúram eLearning Passport™ is a portal that provides access to a range of web-based
training (WBT) courses that cover the functional and technical aspects of the Cúram Business
Application Suite™. The Cúram eLearning Passport™ provides Cúram Business Analysts and
Developers with an accessible way to deepen their knowledge in the functional or technical areas
most appropriate to their project role.
Next Steps
• For more information, contact us at

– learning@curamsoftware.com
• Website
– www.curamsoftware.com/services/training
• Exam Registration
– www.prometric.com/curam
Notes:
Getting Ready for Certification
15. Getting Ready for Certification
15.1. Cúram Certification Exams: Registration Instructions

 When you are ready to take the certification exam, you must contact
learning@curamsoftware.com
 You will be provided with a voucher number via e-mail. This voucher enables you to
schedule your exam. It takes a minimum of five working days to process the voucher.
 Please note that Cúram Software is charged $150 for each exam scheduled
irrespective of whether the exam is taken.
The exam is a web-based test, consisting of 40 multiple-choice questions. Candidates have one
hour to complete the exam. The exam is a closed book exam. It is not permitted to use any
product information, for example, any documents or other artifacts from the Documentation
Center, during the exam.
Cúram Software provides testing sites via its partnership with Thomson Prometric. To schedule
an exam or identify the location of the closest testing centre, access the following URL:
http://www.prometric.com/Curam. This takes you to the Cúram Software home page on the
Thompson Prometric site.
 Select Schedule, Reschedule, or Confirm an Exam.
 To book your exam, select the Schedule an Appointment link.
 Select the country of your choice and state (if applicable) and click Next.
 In the client section, select Cúram Software. In the programme section, select Cúram
Certification. Click Next.
 Click Next.
Select the exam you wish to take and the desired language, in this case, US English. Note:
Although a price is quoted for the exam, there will be no charge once you have entered your
voucher number.
 A list of testing sites is displayed, choose the site that is the most convenient for you and
select Schedule Appointment.
 You will now be asked to log in. If you are already a user, enter your details. If you have
not previously registered on the Prometric site, select Click here in the new user section.
 Complete the form and agree to the Data Privacy Notice and click Submit.
 Your registration is complete. You will receive an e-mail from Thomson Prometric with
further details of the exam. On the confirmation page, click Next.
 Select the time and date you would like to take your exam and click Next.
 In the Promotion Code or Voucher section, click Yes.
 For discount type, select Voucher Number and enter your unique voucher number.
 Click Validate.
Once you have entered your voucher number, your registration is complete.
15.2. Examination Voucher Usage: Terms and Conditions

As some programs use the terms coupon and voucher interchangeably, these terms and
conditions apply to coupon and voucher programs. These terms and conditions must be provided
to candidates and/or customers who receive voucher numbers.
One voucher may be applied towards one exam, delivered at an Authorized Prometric
Testing Center (APTC).
o Vouchers are program-specific and, in some cases, exam-specific. Please
ensure you redeem the voucher for the correct exam.
o Vouchers are not transferable between programs.
Candidates must register for and take their examination prior to the expiration date
provided with the vouchers.
o Voucher expiration dates cannot be extended under any circumstances.
Prometric, Authorized Prometric Testing Centers, and the certifying organization are not
responsible for lost or stolen vouchers or voucher numbers.
Vouchers may not be redeemed for cash or credit, or returned for a refund.
Vouchers may not be applied to exams that have already been taken.
CompTIA vouchers/coupons may be packaged with other products and services but may
not be resold.
Unless bundled with Microsoft-related courseware, any resale and/or transfer of Microsoft
vouchers is expressly prohibited.
To Redeem a Voucher
To register for an exam, visit the Prometric website:
http://www.register.prometric.com/Index.asp
The voucher number must be provided when registering for the exam.
To speak with a Customer Service Representative, please contact the appropriate
Prometric Regional Center for your area. For a complete listing of centers, please visit
http://www.prometric.com/ContactUs/TestTakers
For more information about testing centers in your area or for general information about
Prometric and the exams we deliver, please visit
http://www.prometric.com
For a complete overview of vouchers, including policies, voucher team contact
information, and order forms, visit
http://www.prometric.com/Clients/Vouchers/default.htm
Prometric and Authorized Prometric Testing Center are trademarks of Thomson Learning.
15.3. Cúram Certified Professional (CCP) V6: Sample Exam Questions
1. Which of the following items are provided by the Cúram Enterprise Framework? (Choose
more than one option.)
A. Application Development Environment

B. BI & Analytics
C. Evidence Management
D. Evidence Broker
E. Workflow
2. Which batch job creates financial instructions? (Choose one option.)
A. GeneratePayslips
B. GenerateInstruments
C. DetermineProductDeliveryEligibility
D. GenerateInstructionLineItems
3. Which of the following are types of objectives in the CLASSIC rules framework? (Choose
more than one option.)
A. Objective tag
B. Money
C. Expression
D. Assessment
E. Double
4. Which of the following case types has financials associated with it? (Choose one option.)
A. Assessment
B. Screening
C. Product Delivery
D. Issue
E. Integrated
5. Which workflow activity type is considered to be a null activity because its execution does
not affect the application data nor the business process in any way? (Choose one
option.)
A. Automatic
B. Subflow
C. Parallel
D. Route
E. Event Wait
6. Which Cúram enterprise modules are used by Cúram Outcome Planning to create
assessment questions and process the answers? (Choose more than one option.)
A. Cúram Intelligent Evidence Gathering

B. Cúram Verification
C. Cúram Social Enterprise Collaboration
D. Cúram Decision Assist
7. Which of the following items can be created by a user who is logged in as an

Administrator or System Administrator? (Choose more than one option.)
A. Rule sets
B. Liability Products
C. Benefit Products
D. Participants
E. Rate Tables
8. You are viewing a process flow in the Documentation Center and need to determine the
BPO method that runs the process. Which item will link you to the answer? (Choose one
option.)
A. Process flow circle

B. System rectangle
C. Validation diamond
D. Start oval
9. Which of the following Cúram participant types can remain anonymous? (Choose one
option.)
A. Representative
B. Product Provider
C. Person
D. Service Supplier
E. Prospect Person
10. Which of the following tasks must be completed before a product delivery case is
activated? (Choose more than one option.)
A. Generate the payment

B. Activate the evidence
C. Run the financial batch suite
D. Reassess the decision
E. Submit the case for approval
Answers
1. A, C, E
2. B
3. B, D, E
4. C
5. D
6. A, D
7. A, B, C, E
8. D
9. E
10. B, E

CB600 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CB600 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Fundamentals of the Cúram Enterprise

Framework (V6) for Business Analysts

Publication date: 27 October, 2011

1. An Introduction to Cúram Software

After completing this course, you will be able to

After completing this lesson, you will be able to

Cúram Software’s mission is to provide best-in-class, COTS-based

Social Enterprise Management (SEM)

Social Enterprises are A business and technology

Social Military and

UI Benefits TANF Medicaid Income Support Disability

Business and Technology

Customers Around the World

Cúram Business Application Suite™

Cúram Enterprise Framework™

The foundational infrastructure and functionality at the

Case Management: Common Intake, Evidence Management, Participant Management, Eligibility

Business Services: Task Management, Search, Calendaring/Scheduling, Correspondence

Administration Suite: Online configuration by the system administrator

Application Development Environment (ADE): Coding/development/customization by developers

Cúram Enterprise Modules

Specialized functionality applicable to many agencies

Cúram Enterprise Modules, continued

• Cúram Intelligent Evidence Gathering™

Cúram Outcome Management: Uses Outcome Plans to manage assessments, objectives,

Cúram Business Process Modules

Processes and functionality for specific types of

Cúram for Income Support: Cash and food programs

Cúram for Medical Assistance: Medical programs

Cúram for Child Welfare: Child protection, child welfare, adoption

Cúram for Child Care: Subsidized child care

Cúram for Youth Services: Youth justice programs

Cúram for Workers‟ Compensation: On-the-job injuries, illness, and rehabilitation

Cúram for Child Support Enforcement: Child support programs

In this lesson, you have covered the following topics:

2. The Cúram User Interface

After completing this lesson, you will be able to

Three Major Components of the UI

• Application logo • Welcome message

Application name – Customers can change the application name.

Tab Title Bar

Tab Content Page

Page Group Navigation Bar

Home Pages and Pods

Other Icons and Buttons

• Magnifying glass (Search)

Refresh – Clicking this button refreshes the content of the page.

In this lesson, you have covered the following topics:

3. Cúram Participant Management

• After completing this lesson, you will be able to

• A party that has a direct or indirect interaction with

Cúram Participant Role Types

Representative Concern Role

Common Participant Elements

• Address • Email address

Interactions: A list of interactions provides information on all of a participant's communications

• A Person is an individual who has registered with

Alternative Name – Any name recorded for a person or prospect person.

• A Prospect Person is an individual…

Merging Duplicate Records

• Information can be merged from a Person record to

• An Employer employs one or more persons,

Employer-specific data includes the following: