· Web view2016. 3. 24. · SAMS is designed very differently from SDMT. SAMS is a rule based system which can store additional and more detailed information than SDMT. There are

Working with Converted Data from SDMT to SAMS Reference Guide

This guide provides specific information regarding the impact of the Data Conversion Process on Service Delivery Model Technology (SDMT) data converted to SAMS. The User Guide Table of Contents has been divided into specific Topics and Areas for reference. Individual sections of this document can be accessed using the corresponding hyperlinks.

Background

Data Conversion is the process used to transfer the data (information) from SDMT to SAMS. The Data Conversion Process occurred November 6-10, 2014, to enable SAMS to go live on November 11, 2014.

SAMS is designed very differently from SDMT. SAMS is a rule based system which can store additional and more detailed information than SDMT. There are mandatory fields in SAMS to accommodate information that was never recorded in SDMT. For this reason, as part of the conversion process ‘fake’ data was created to satisfy the rules in SAMS where a new mandatory field must contain data.

When the information from SDMT was transferred into SAMS, all fields were not necessarily compatible. For example, Social Insurance Numbers (SINs) in SAMS require hyphens (e.g. 123-456-789) for a correct format, while SDMT did not require them. In cases like this, specialized data conversion processes were required. This User Guide covers the specific effects of data conversion from SDMT and the results in SAMS.

Effective April 4, 2016, SDMT will be accessed thru the Cognos Reporting Tool Social Assistance Legacy Information (SALI) link. Refer to SAMO Communication 37-16 for further detail.

Table of Contents

1. General................................................................................................................6i. SDMT Cases Eligible for Conversion.................................................................6ii. What did not Convert from SDMT.....................................................................6iii. SDMT Member ID Number................................................................................7iv. “Do Not Use” Members....................................................................................7v. SDMT Members with Unpopulated Gender Field..............................................7vi. SDMT Reason for Applying = ‘Emergency Assistance’.....................................8vii. Case Org Conversion........................................................................................8viii. SDMT Terminated Cases after January 1, 2013............................................9ix. Conversion of SDMT Cases with Overpayments...............................................9

SAMS USER GUIDE 1 Working with Converted Data SDMT to SAMS

March, 2016

https://www.samo.css.gov.on.ca/resources/communications/sat/comupdates/2016/documents/37-16CognosReportingToolAdditionoftheSALIlink.pdf

x. Conversion of SDMT Cases with Written off Overpayment Eligible for Reactivation9

xi. Case Status: SDMT to SAMS...........................................................................9xii. SDMT Cases with DAU Referrals.....................................................................10xiii. SDMT Verification Checklist Items and SAMS Verification Items.................10

2. Participants........................................................................................................11i. SDMT Member ID...........................................................................................11ii. SDMT Benefit Unit ID......................................................................................11iii. SDMT Mailing Address....................................................................................12.............................................................................................................................. 12iv. Merging of Duplicate SDMT Contacts.............................................................13v. SDMT Non-Contributing Members..................................................................13vi. Populating Case Participants..........................................................................13

3. Case Management.............................................................................................15i. Manual SDMT Tasks.......................................................................................15ii. SDMT Program Eligibility List..........................................................................15

4. Restricted File Access & Safety/Service Delivery Flags.....................................16i. Restricted File Access....................................................................................16ii. Safety / Service Delivery Flags.......................................................................17

5. Evidence............................................................................................................18i. Start and End Dates of Income Records & Asset Records..............................18ii. Financial Independence.................................................................................18iii. SDMT Immigration Details..............................................................................19iv. SDMT System Generated Income Exemption.................................................21v. SDMT Income – Net Earnings Field.................................................................22vi. SDMT Resource Income..................................................................................23vii. SDMT Income Type – “CPP/QPP – Other”........................................................24viii. SDMT Income Type – Not Employed...........................................................25ix. SDMT Income Type – Children’s Lawyer/Public Trustee.................................26x. SDMT Income Type – Emergency...................................................................27xi. SDMT Income Type – Ontario Works..............................................................28

SAMS USER GUIDE 2 Working with Converted Data SDMT to SAMSMarch, 2016

xii. SDMT Income Type – Segregated Funds........................................................29xiii. SDMT Income Type – Superannuation........................................................30xiv. SDMT Income Type – Other.........................................................................31xv. SDMT Income Type – Loan / Grant / Awards-Education-Non OSAP.................32xvi. SDMT Income Type – Student Award / Bursary / Scholarship......................33xvii. SDMT Income Type–Childcare Expenses and Disability Related Expenses. 34xviii. SDMT Income Type – Support.....................................................................35xix. SDMT Income Verification Required Checkbox...........................................36xx. SDMT Income Reporting Required Checkbox.................................................36xxi. SAMS Income Reporting Evidence..............................................................38xxii. SDMT Institution Accommodation Types.....................................................40xxiii. SDMT Accommodation Costs......................................................................41xxiv. SDMT Negative Shelter Expenses...............................................................42xxv. SDMT Support Records with Termination Date of 04/04/2444....................42xxvi. SDMT Assets with Negative Amounts.........................................................42xxvii. Special Diet Dates......................................................................................43xxviii. Special Diet Age Related Items...................................................................43xxix. SDMT Negative Override Amount...............................................................44xxx. SDMT $0.00 Override of Basic Assistance Amounts....................................44

6. Overpayments...................................................................................................46i. Converted Overpayments..............................................................................46ii. Reactivation of Written off SDMT Overpayments...........................................48iii. SDMT Terminated Cases with Overpayments................................................48iv. Referring a Converted Overpayment to the Overpayment Recovery Unit (ORU)

48

7. Additional Benefits.............................................................................................49i. Benefits in Requested State...........................................................................49ii. SDMT Release Date........................................................................................50

8. Outcome Plans...................................................................................................50i. Participation Agreement Conversion..............................................................50

9. Assistance for Children with Severe Disabilities (ACSD)....................................52


i. Child Information Evidence............................................................................52ii. ACSD Family Count Evidence.........................................................................54iii. Specialized Child Expenses............................................................................55iv. Taxed Income Evidence.................................................................................57

10. Tips and Tricks for Working with Converted Data..............................................58i. What does Baseline Eligibility mean?.............................................................58ii. No Baseline Amount.......................................................................................59iii. Cases that did not Baseline............................................................................60iv. Incorrect Baseline Amount.............................................................................60v. Baseline Overpayment and Baseline Underpayments / Arrears.....................62vi. Understanding Why there are Multiple Product Delivery Cases.....................63vii. Where to Find SDMT and SAMS Eligibility Amounts........................................64viii. Where to find SDMT and SAMS Payment Information.................................65Integrated Case Financials Tab.............................................................................65Product Delivery Case Financials Tab...................................................................65Person Financial Tab.............................................................................................66Additional Benefit case Financial Tab...................................................................66Comparing SAMS and SDMT Payments.................................................................66Payment Instrument History.................................................................................67ix. Important Tips When Making Changes on a Case..........................................67Compare the SDMT Entitlement Amount to the SAMS Entitlement Amount..........67Check for Override Evidence.................................................................................68Make Changes One at a Time and Check for New Overpayments and Underpayments.............................................................................................................................. 68Unexpected Entitlement Amounts........................................................................68Arrears Payments for the Conversion Period.........................................................68Converted Cases that Did not Baseline, or have No Baseline Eligibility................69Cases Stuck in “Open” Status – Updated March 2015..........................................70x. Investigating SAMS Overpayments and Underpayments...............................70xi. Product Delivery Cases Suspended Because of Baseline Errors.....................70Identifying if the Product Delivery Case is Suspended for Baseline Errors............71Steps for Closing Baseline Error Suspended Product Delivery Cases....................72


Notes on Creating the New Product Delivery Case Application.............................75

11. Updating Secondary Contributors......................................................................76

12. Converted Disability Type Evidence for ODSP...................................................81i. Update the Disability Determination Type.....................................................82ii. Review/Cancel the Letter...............................................................................82iii. Modify Payment Type.....................................................................................83

13. Two Converted ODSP PDCs................................................................................83


1. General

i. SDMT Cases Eligible for Conversion

The following criteria were used to determine which Benefit Units in SDMT were converted to SAMS:

The date selected to determine if a Benefit Unit is eligible for conversion was January 1, 2013.

If a Benefit Unit was found to be eligible for conversion, all Members found on this BU converted regardless of the Jan 1, 2013 cut-off date.

All Benefit Units that previously had an ongoing case status in SDMT with an End Date (Termination Date) greater than January 1, 2013 were converted to SAMS.

All Benefit Units with a member that had an outstanding overpayment balance greater than $0.00 were converted to SAMS.

All Benefit Units with a Member with a written-off overpayment that was eligible for reactivation were converted to SAMS. o Write-Off – Director Approval o Write-Off – Under $10 o Write-Off – Less than $20 o Write-Off – Between $20 and < $500 o Write-Off – Between $500 and >= $5000 o Write-Off – Deported o Write-Off – FBA Not Applicable SARB o Write-Off - GWA o Write-Off – Negotiated Settlement

All Benefit Units with a Member with a DAU referral were converted to SAMS.

ii. What did not Convert from SDMT

The following was not converted from SDMT to SAMS:

Notes – with the exception of ODSP Active Case Management notes System Generated Tasks Members with the term ‘DO NOT USE’ in their name Evidence Records with an end date prior to January 1, 2013 Items on the Verification Checklist

iii. SDMT Member ID Number


The SDMT Member ID converted as the SAMS Reference Number.

iv. “Do Not Use” Members

All Benefit Unit Members with the term DO NOT USE found in their first name or given name in SDMT did not convert.

If the “Do Not Use” member was the applicant, the case itself did not convert, and none of the other members on the case converted.

If the “Do Not Use” member was a spouse, dependent child, or dependent adult, only that member was excluded from conversion, and all other members within the case converted normally.

v. SDMT Members with Unpopulated Gender Field

All Members with a “blank” gender field in SDMT converted as “Male” in SAMS.

vi. SDMT Reason for Applying = ‘Emergency Assistance’


In SDMT, OW cases with a reason for applying of “Emergency Assistance” did not convert as a regular OW case, since the reason had been misused in SDMT to provide ongoing OW benefits.

All information populated for regular OW cases (as noted within this document) was applicable for SDMT Emergency Assistance cases converted as a regular OW case. For example, shell outcome plans created for the applicant, spouse, and any members over the age of 18. The comments on the home page for Emergency Assistance cases read Emergency Assistance.

vii. Case Org Conversion

If more than one staff member was assigned to a single case org in SDMT, the case was assigned to the unassigned work queue of the given local office in SAMS.

In SDMT, sites had the ability to assign more than one staff member to a case org number. This was often used when staff were job sharing or in specialty case orgs. In SAMS, only one staff member can be assigned as the case owner. Activities were in place at the site level, to make the necessary changes to the case org in the SDMT prior to the Crossover Period. This minimized the number of cases assigned to the “Unassigned Cases” Work Queue at conversion.

viii. SDMT Terminated Cases after January 1, 2013


All Benefit Units that previously had an Ongoing case status in SDMT with an End Date (were Terminated) greater than January 1, 2013 converted to SAMS.

ix. Conversion of SDMT Cases with Overpayments

All Benefit Units with a member that had an outstanding overpayment balance greater than $0.00 converted to SAMS.

x. Conversion of SDMT Cases with Written off Overpayment Eligible for Reactivation

All Benefit Units with a Member with a written-off overpayment that was eligible for reactivation converted to SAMS. Reactivation of a written off overpayment will require the user to create a manually adjusted overpayment. All SDMT converted O/P's that are eligible for reactivation converted into an ‘open’ status in SAMS.

The following are examples of specific types of write-off criteria found in SDMT:

o Write-Off – Director Approval o Write-Off – Under $10 o Write-Off – Less than $20 o Write-Off – Between $20 and < $500 o Write-Off – Between $500 and >= $5000 o Write-Off – Deported o Write-Off – FBA Not Applicable SARB o Write-Off - GWA o Write-Off – Negotiated Settlement

xi. Case Status: SDMT to SAMS

Cases were converted to SAMS based on their status in SDMT at the time of conversion.The following table illustrates ‘SDMT Case Status’ and the corresponding ‘SAMS Case Status’ when converted to SAMS.

SDMT Case Status SAMS Case StatusScreening OpenVerification OpenAwaiting DAU OpenOngoing Active


Suspend (manual or system generated)

Active with a Manual Suspend (Evidence)*

Chose to Discontinue ClosedTerminated ClosedIneligible Closed

If a case was suspended in SDMT, a manual suspension converted into SAMS. As per the user guide, Manually Changing Eligibility Status of a PDC. A case that was manually suspended in SAMS did not automatically terminate by the system. Note that SDMT cases in Screening, Verification + DAU did not convert as application cases.

xii. SDMT Cases with DAU Referrals

All Benefit Units with a Member with a DAU Referral converted to SAMS.

xiii. SDMT Verification Checklist Items and SAMS Verification Items

SDMT Verification Checklist Items did not convert into SAMS. A post-implementation cleansing activity was distributed to identify all items on the SDMT ‘Verification Checklist’ for which verification had not been received at the time of conversion.

Since SAMS requires verification for all evidence records, all converted evidence has a corresponding SAMS verification item with a status of “Verified”. Should any of these items have been on the SDMT ‘Verification Checklist’, they were identified in the post-implementation activity and the SAMS verification changed.

If the SDMT ‘Verification Checklist’ due date was prior to the SDMT shut down date (November 6), the case would have suspended or terminated in SDMT and the case status converted accordingly.

If the SDMT ‘Verification Checklist’ due date was after the SDMT shut-down date (November 6), this did not have an impact in SAMS. If the Verification Checklist item was related to current evidence, the caseworker will need to manually change the SAMS verification item on the appropriate evidence to “Not Verified” and populate the proper verification due date in order for SAMS rules to suspend the case accordingly.

2. Participants

i. SDMT Member ID


https://www.samo.css.gov.on.ca/ld/sams/documents/SAMSUserGuide/new/changing-eligibility.docx

The SDMT Member ID will correspond with the SAMS Reference Number, which is an Alternate ID. To verify the SAMS Reference Number to the SDMT Member ID, follow the procedures detailed below:

SAMS Home From the Primary Client Person page. Select the Personal Information tab. Select Alternative IDs from the side panel.

Take note of the Alternative ID field value that corresponds with the SAMS Reference Number type. This is the SDMT Member ID.

SDMT Open the SDMT environment. Select Search. Enter the SDMT Member ID. Select Search.

The participant record is displayed in Search Results if it exists. Otherwise, the message “There are no matching items based on the Search Criteria entered” is displayed.

ii. SDMT Benefit Unit ID

The SDMT Benefit Unit ID will correspond with the SAMS Integrated Case ID. To verify the SAMS Integrated Case ID to the SDMT Benefit Unit, follow the procedures detailed below:

Verifying the SAMS Integrated Case ID to SDMT Benefit Unit

SAMS Home From the Integrated Case page, select the Primary Client under the Programs

section. Select Primary Client Select the Cases tab.

Take note of the Reference field value that corresponds with the Integrated Case name. This is the SAMS Integrated Case ID.

SDMT Open the SDMT environment. Select Search. Enter the SDMT Member ID.


Select Search. The participant record is displayed in Search Results if it exists. Otherwise, the message “There are no matching items based on the Search Criteria entered” is displayed.

Select the hyperlink within the Surname field. Select the Benefit Unit Summary panel. Locate the Benefit Unit ID field and verify with the SAMS Integrated Case ID.

iii. SDMT Mailing Address

If an alternate address existed in SDMT, two addresses converted to SAMS for the historical period. The first was the Mailing Address and second was the Personal Address. The Mailing Address was set as the Primary Address and all information will be mailed to this address.

iv. Merging of Duplicate SDMT Contacts At conversion, SDMT contacts merged based on the name of the contact and address information for the contact. If two contacts had identical names and addresses, they were merged into one upon conversion. This should not impact any past payments made to these contacts.


Contacts were not merged if there were inconsistencies between the name and address of the two contacts (this includes punctuation such as commas and dashes, as well as the order in which address is populated).

v. SDMT Non-Contributing Members

If a member was Non-Contributing in SDMT, a record was created on the ‘Sanction’ page in SAMS. The ‘Sanction’ Page is accessed via the Integrated Case ‘Compliance’ Tab and selecting ‘Sanctions’ on the left side bar. This will ensure that the member is not included in the entitlement calculation for the appropriate periods.

vi. Populating Case Participants

SAMS requires Participants for many types of evidence. Many of these Participants were not recorded in SDMT and Fake Participants were created by the conversion process to satisfy the ‘mandatory field’ rules in SAMS. The conversion process took the word “FAKE” and entered it into any mandatory field in SAMS for which there was no information in SDMT. After Go-Live this evidence can be updated on a “touch the file” basis. The following are examples of Fake Participant Data input into SAMS, as a result of the conversion process:

Schools Funeral Home Life Insurance Companies Asset Holders (i.e. Liquid Resources) Medical Institutions


Utilities Trust Fund Holder Special Diet Provider Employers (Self-Employment Records) Contributors

Example of Fake Participant Data: School Name

3. Case

i. Manual SDMT Tasks

All manually created tasks in SDMT converted to SAMS manually created tasks. No system generated SDMT tasks converted.


ii. SDMT Program Eligibility List

For the conversion period, an SDMT Information tab can be found under each Determination found in SAMS. This SDMT Information tab contains the details found on the most current decision for the Benefit month on the SDMT ‘Program Eligibility Details’ page. This tab is for informational purposes only. Note, when performing a Retroactive Budget Calculation, this tab should be referenced for each impacted benefit month, to ensure that the SDMT and SAMS amounts align.

4. Restricted File Access & Safety/Service Delivery Flags

i. Restricted File Access

In SAMS, Restricted File Access is managed by Sensitivity Levels. SDMT Client files, without Restricted File Access, were converted to SAMS with a Sensitivity Level of ‘1’.


SDMT Client Files with a Note Category of “Flag - Restricted File Access” were converted to SAMS with a Sensitivity Level of ‘2’.

SAMS Users are only permitted to view secured data if their sensitivity level is equal to or higher than the data's sensitivity level. In instances where information should be protected and reserved for viewing by limited and select Users, a higher sensitivity level can be applied to the sensitive data. Refer to the following SAMS User Guides for detailed information for managing the Administration of SAMS User’s Sensitivity Levels:

ADM001 Local Admin Maintain Users [Updated October 14, 2014]

SAMS Field Office Security Roles [Updated October 14, 2014]

ii. Safety / Service Delivery Flags

A Special Caution converted into SAMS if there was a SDMT Note Category of “Flag – Safety” or “Flag – Service Delivery” and the Note Type was one of the following:

• Blind/Visual Impairment• Cheque Pick-Up• Deaf/Hearing Impairment• Interpreter/Translator Required• Medically Vulnerable


https://www.samo.css.gov.on.ca/ld/sams/documents/SAMSUserGuide/SAMS%20Field%20Office%20Security%20Roles.xlsx

https://www.samo.css.gov.on.ca/ld/sams/documents/SAMSUserGuide/ADM001%20Local%20Admin%20Maintain%20Users.doc

• Mobility/Motor Impairment• Off-Site Home Visit Required• Speech Impairment• Sterile Precautions• Trustee• Unsuitable for IVR• TTD/TTY User• Unsuitable for Mail-Outs• Hazardous Address• Threatening Behaviour• Threatening Co-Resident/Visitor• Trespass Notice• Violent Behaviour• Warning Alerts Received

5. Evidence

i. Start and End Dates of Income Records & Asset Records

At conversion, the start and end dates of some SDMT income records or asset records may have been modified when created as evidence in SAMS, so that they matched the case status of the applicable case member.

For example: An income record with an end date later than the date that member was removed from the benefit unit may be modified when created in SAMS.


Dates will be determined based on the following criteria:

Start date The latest date of:the record start datethe Benefit Unit start datethe Member start date

End date The earliest date of:the record end datethe Benefit Unit end datethe Member end date

ii. Financial Independence

In SDMT, financial independence was recorded by answering the questions contained on the ‘Accommodations’ page.

In SAMS, financial independence is recorded by completing the Financial Independence evidence record (Household – Other section).


At conversion, a Financial Independence evidence record was created for any recipient under the age of 18, and for any recipient who had “yes” selected for the question “Are you living with your parents or the parents of your spouse?” on the ‘Accommodation’ page in SDMT.

Post conversion, financial independence evidence is only created when required.

iii. SDMT Immigration Details

In SDMT, immigration details were captured on the ‘Immigration/Institution Details’ page and accessed from the ‘Member Details’ page. As SDMT immigration records were sorted by the start date of the record and not the arrival date, there was potential for overlap of arrival dates if there were numerous immigration records for the same person.

In SAMS, immigration details are captured as Immigration Evidence.

At conversion, the “start date” on the ‘Immigration’ page in SDMT was used as the “Arrival Date” in SAMS. If the SDMT Immigration start date was not populated, then


the recipient’s earliest grant date was used as the “Arrival Date” in SAMS. This avoided the converted data creating overlapping Immigration Evidence records.

iv. SDMT System Generated Income Exemption

Based on Ontario Works/Ontario Disability Support Program legislation, some types of income are exempt. When income records for these types of income were created in


SDMT, the income exemption field defaulted to “System Generated”. This income was then recorded but did not impact eligibility.

In SAMS, the “monthly exempted amount” and the “exemption reason” must be populated in the income evidence record to exempt the income from eligibility.

At conversion, any SDMT income records with the exemption reason “System Generated” converted to the appropriate SAMS income evidence record with the Exemption Reason of “Other Exemption Approved by Administrator/Director.”

v. SDMT Income – Net Earnings Field


In SDMT, when the monthly gross amount was populated for an earnings type record, the net earnings amount was system calculated, based on the client’s claim code and related tax tables.

For other types of income, the net earnings amount field did not automatically populate.

At conversion, where there was "Net Earnings Amount" in SDMT, that amount converted into both the "Amount" and "Monthly Amount” fields in SAMS. The SDMT "Monthly Gross Amount" converted to SAMS for SDMT income types that did not use the "Net Earnings Amount".


vi. SDMT Resource Income

In SAMS, the following items are input as a “Resource Income” evidence record:

A “Resource Income” evidence record (child record) must have an associated “Liquid Resource” evidence record (parent record).

At conversion, any SDMT income records that converted to “Resource Income” evidence have a corresponding “Liquid Resource” evidence record created containing default data.


vii. SDMT Income Type – “CPP/QPP – Other”

In SDMT, the income type “CPP/QPP – Other” was used to capture Canada Pension Plan or Quebec Pension Plan income that did not fall into the two other CPP/QPP income types (CPP – Disability Benefits or CPP – Death Benefits). It was often used to record Canada Pension Plan Retirement Benefits.

At conversion, income records in SDMT under “CPP/QPP –Other” converted to a CPP-Retirement evidence record with the phrase “CONVERSION CPP-OTHER” in the comment section of that record. As there is no income type of CPP-Other in SAMS, CPP-Retirement is the best match of the rules associated with that SDMT benefit type.


viii. SDMT Income Type – Not Employed

In SDMT, if a recipient was not employed, there was not an Earnings income record on the Income and Expense List. As well, the response to the question “Are you, your spouse, or any of your dependents currently receiving any earnings?” was “No”.

In SAMS, if a recipient is not employed, there must be an Income Reporting evidence record indicating the reason for no earnings as Not Employed.

At conversion, Income Reporting evidence was created for all benefit units that did not have earnings to waive the income reporting requirement for one year. These records had an end date of 30/11/2015 (ODSP) or 15/11/2015 (OW).


ix. SDMT Income Type – Children’s Lawyer/Public Trustee

In SDMT, income received from a trust held by a Children’s lawyer or Public Trustee was input under this income type.

In SAMS, income from this type of source is input as Trust Income evidence.

At conversion, SDMT Children’s Lawyer/Public Trustee income records converted to a “Trust Income” Evidence record in SAMS. SAMS also created a corresponding “Trust” evidence record (parent page) containing default data.

x. SDMT Income Type – Emergency


In SDMT, an income record was input under the type “Emergency”. This income was then deducted from the recipient’s entitlement.

In SAMS, Emergency assistance income is input as unearned income.

At conversion, an SDMT income record with the type “Emergency” converted to an Unearned Income evidence record, with an Unearned Income type of “Other Income”.

xi. SDMT Income Type – Ontario Works


In SDMT, income received from Ontario Works that was required to be deducted from the recipient’s entitlement was input under the type “OW”.

In SAMS, income received from Ontario Works that is required to be deducted from the recipient’s entitlement is input as “Benefit Income”.

At conversion, income records that have the type “OW” created a “Benefit Income” evidence record. The benefit type is “Other Government Income – Other” and the benefit source is “Other Government Income”.

xii. SDMT Income Type – Segregated Funds


In SDMT, income received from a Segregated Fund was recorded under the income type “Segregated Funds”.

In SAMS, income from a segregated fund is input as a “Resource Income” evidence record.

At conversion, an SDMT Segregated Fund income record converted to “Resource Income” evidence in SAMS. The Resource Income type is “Interest”. A corresponding “Liquid Resource” evidence record was created, and contains default data (see screenshot under the SDMT Resource Income section).

xiii. SDMT Income Type – Superannuation


In SDMT, income received from Superannuation was recorded under the income type “Superannuation”.

In SAMS, income from superannuation is input as a “Resource Income” evidence record.

At conversion, a SDMT Superannuation income record converted to “Resource Income” evidence in SAMS. The Resource Income type is “Interest”. A corresponding “Liquid Resource” evidence record was also created, and contains default data (see screenshot under the SDMT Resource Income section).

xiv. SDMT Income Type – Other


In SDMT, income that did not fit into any of the listed types was input as “Other Income”.

In SAMS, income that does not fit into any other income evidence type will be input as “Unearned Income”.

At conversion, SDMT income records with the type “Other Income” converted to “Unearned Income” evidence with the type “Other Income”.

xv. SDMT Income Type – Loan / Grant / Awards-Education-Non OSAP


In SDMT, funds received by a recipient for education through a loan, grant or award, (other than Ontario Student Assistance Program (OSAP) loans) was recorded as an income record under the type of “Loan/Grant/Award-Educ-Non OSAP”.

In SAMS, this type of income is recorded as “Benefit Income”.

At conversion, income records under the type “Loan/Grant/Awards-Educ-Non OSAP” converted to Benefit Income evidence records with a benefit type of “Student Award or grant – Personal Living Allowance” and a benefit source of “Student Loans and Awards”.

xvi. SDMT Income Type – Student Award / Bursary / Scholarship


In SDMT, awards, bursaries and scholarships received by a recipient were recorded as an income record with the type “Student Award/Bursary/Schl”.

In SAMS, this type of income is recorded as “Benefit Income”.At conversion, income records under the type “Student Award/Bursary/Schl” converted to Benefit Income evidence records with a benefit type of “Student Award or grant – Personal Living Allowance” and a benefit source of “Student Loans and Awards”.

xvii. SDMT Income Type–Childcare Expenses and Disability Related Expenses


In SDMT, childcare expenses and disability related expenses were recorded as expense records on the Income and Expense List.

In SAMS, childcare expenses and disability related expenses are recorded as ‘Dependent Care Expense’ or ‘Employment Expense’ evidence (one time parent record) with monthly ‘Expense Report Stub’ evidence required in order for the earnings to be reduced.

At conversion, SDMT Childcare Expense records and SDMT Disability Related Expense records converted to the parent ‘Dependent Care Expense’ or ‘Employment Expense’ evidence. ‘Expense Report Stub’ evidence was not required to support eligibility for the period prior to November 1, 2014.

Note: The expenses were required to be input as ‘Expense Report Stub’ evidence in SAMS effective November 1, 2014 to ensure the correct entitlement was issued for the first monthly payment post-conversion.

xviii. SDMT Income Type – Support

In SDMT, child and spousal support details were populated in the ‘Support List’.


If support is to be deducted from the recipient’s entitlement, a support income record was created in the ‘Income and Expense List’.

In SAMS, the following evidence records must be populated to record and deduct/waive child and/or spousal support:

At conversion, information from the SDMT support list converted to populate the evidence above.

SDMT Support Income records converted to “Unearned Income” evidence with the type “Deemed Support”.


Note: Post conversion, the converted “Deemed Support (Unearned Income)” evidence had to be end dated and new “Child Support Payment” evidence that links to the converted support related pages created.

Further details were provided for post conversion activities.

xix. SDMT Income Verification Required Checkbox

The SDMT Income Verification Required Checkbox was not converted to SAMS. If this box was selected in SDMT, it did not have any impact on the converted information in SAMS.

xx. SDMT Income Reporting Required Checkbox

The SDMT Income Reporting Required Checkbox was converted into the “Monthly Reporting Required” indicator in SAMS. If the Income Reporting Required checkbox was populated in SDMT, then all current incomes converted to SAMS with the “Monthly Income Reporting” indicator selected. All SAMS income evidence records required Income Reporting evidence (see Income Reporting section). This applies to the following SAMS income types:


The “Monthly Income Reporting” checkbox can be deselected in SAMS on the above income records on an individual basis.

Note: If there was not an Earnings Income Record in SDMT, Income Reporting evidence with a 12 month waiver was created at conversion to ensure that cases did not suspend for failure to report non-earnings income.

Special Note for ODSP:


In ODSP, recipients are not required to report monthly on income, other than earnings, unless there is a change to their income. However, during the conversion of data from SDMT to SAMS, it was not possible to map the income reporting checkbox to a variety of scenarios. Therefore, if the SDMT Income Reporting Required checkbox was selected and there were SDMT income records in addition to earnings, all of the income records converted with the Monthly Reporting Required checkbox selected.

A post-implementation cleansing activity took place to identify all ODSP cases with Monthly Reporting Required selected for income records other than Earnings.

xxi. SAMS Income Reporting Evidence

In SAMS, the evidence called Income Reporting is used to validate that all income that is required to be reported prior to payment processing has been reported. Further details for its use in SAMS are contained in the user Reporting Income user guide.

If the Monthly Reporting Required checkbox has been selected for an income record in SAMS, then an Income Reporting evidence record will be required.

An Income Reporting evidence record was not created during conversion if a current Paid Employment record was created. A “current Paid Employment record” means that there was SDMT income for Earnings, Training Allowance, or Nominal Remuneration converted, and the SDMT income does not have a Final Pay Date or the Final Pay Date is greater than the conversion date.

If the Income Reporting Required checkbox was selected on the ‘Paid Employment record(s), then the caseworker was required to create an Income Reporting record in SAMS for the case to be eligible going forward in SAMS. If the Income Reporting Required checkbox was not selected for the Paid Employment record(s), then Income Reporting is not required.

NOTE: Earnings input into SDMT for period of October 1 – 31 (ODSP) or October 16 – November 15 converted to Paid Employment and Earned Income Evidence in SAMS. Income Reporting Evidence was created to apply these earnings to the appropriate month’s entitlement – November 30 (ODSP) or December 1 (OW). This would have been done prior to November pay run.

If there was no current Paid Employment evidence record created during conversion (there was not a current Earnings, Training Allowance or Nominal Remuneration income record in SDMT), then an Income Reporting evidence record was created automatically. The Income Reporting Evidence record was created regardless of whether or not there were other types of income records converted (for example: Benefit Income, Resource Income, etc.), and regardless of whether the SDMT Income Reporting Required checkbox was selected.


https://www.samo.css.gov.on.ca/ld/sams/documents/SAMSUserGuide/new/reporting-income.docx

Income Reporting evidence records created by conversion had been populated with an End Date equal to the conversion date plus 12 months. This provided a 12 month grace period on Income Reporting on integrated cases that had no current Paid Employment records converted. These records had to be updated prior to November 2015.

For further details on income reporting, please see the chart below.

xxii. SDMT Institution Accommodation Types

In SDMT, the accommodation type on the SDMT ‘Accommodation’ page determined the correct entitlement for the benefit unit (PNA, institution rate, shelter, etc.).


In SAMS, institution details are captured as “Institution” evidence and the client’s entitlement is impacted by the type selected in the “Living Expenses” evidence.

At conversion, Institution evidence records were created for each member within the SDMT Benefit Unit when the SDMT ‘Accommodation Page’ had an accommodation type of any of the following:

This was done to ensure that SAMS eligibility matched SDMT by making sure the entire Benefit Unit was determined compliant, rather than just the applicant.

** For the accommodation type “Correctional Facility” this was done to ensure that the entire benefit unit is determined non-compliant, rather than just the applicant.

xxiii. SDMT Accommodation Costs

In SDMT, a recipient’s shelter entitlement was influenced by the accommodation type selected and the “Expenses” records were input on the ‘Accommodations’ page. The


“Expenses” selected should correlate to the “Accommodation Type”, but was not a requirement to make the benefit unit eligible.

In SAMS, a recipient’s “Shelter Expense” evidence must correspond with the “Living Arrangement” evidence. For example: if the Living Arrangement evidence is renting, the shelter expense must be rent; it cannot be mortgage.

As the shelter expense types in SAMS do not all match exactly to the expense types in SDMT or SDMT Accommodation Types and SDMT Expense Types do not correspond, extensive mapping was required.The tables below show how the mapping to SAMS will occur.

Where the SDMT Accommodation Type is OWNED HOME:

Shelter Expense (SDMT) Expense Type (SAMS)Condo Maintenance FeesFire Insurance Home InsuranceMortgage MortgageTaxes Property TaxesBoard and Lodge Maintenance FeesRent Maintenance Fees

Where the SDMT Accommodation Type is Rent, Renting Subsidized, Home For The Aged, Chronic Care Facility, Community Resource, DS Apt Program, Domiciliary Hostel, DS Group Living, Home For Special CA, Homeless/Transient, Interval/Transition, Non Aged Home/CIA, Nursing Home, Residential School, Addiction Treatment, Psychiatric Hospital/Facility, DS Facility For Dev, Correctional Facility:

Shelter Expense (SDMT) Expense Type (SAMS)Rent RentCondo Maintenance FeesMortgage RentFire Insurance Home Insurance


Taxes RentBoard and Lodge Rent

Where the SDMT Accommodation Type is: BOARD AND LODGING, DS APT PROGRAM-BOA, and DOMICILARY HOSTEL:

Shelter Expense (SDMT) Expense Type (SAMS)Any shelter expense type Defaults to Board and Lodge

xxiv. SDMT Negative Shelter Expenses

Shelter Expenses in SDMT with a negative expense amount were not converted into SAMS.

xxv. SDMT Support Records with Termination Date of 04/04/2444

In SDMT, support records could not be deleted. The termination date of 04/04/2444 was used as a workaround for this reason.

At conversion, SDMT Support records with a termination date of 04/04/2444 did not convert.

xxvi. SDMT Assets with Negative Amounts

Negative asset values, found in SDMT, converted to SAMS with a value of $0.00.

xxvii. Special Diet Dates

Special diet records had the start and end dates modified to ensure that they did not exist during periods that a benefit unit was terminated.


xxviii. Special Diet Age Related Items

Special Diet items of Allergy to Milk/Milk Products and Lactose Intolerance have amounts that vary based on the member’s age. In SAMS, this amount is automatically determined based on the member’s age. In SDMT, there was a process of manually changing the amount when the member had a birthdate.

After conversion, the amount of special diet in SAMS may be different than the amount issued in SDMT. This will occur if the amount had not been properly adjusted, and was incorrect in SDMT. The amount issued in SAMS will be the correct amount.

In SAMS, an override to a recipient’s eligibility is made by creating “Override” evidence.


At conversion, an override on the ‘Program Eligibility List’ in SDMT converted to Override evidence.

Note: If an end date was populated by conversion on override evidence, this date cannot be extended beyond the converted end date. To extend the override further into the future, the end date is left as is, and a new override evidence record can be created for the future period.

xxix. SDMT Negative Override Amount

Program Eligibility Overrides in SDMT with a negative amount were not converted into SAMS.

xxx. SDMT $0.00 Override of Basic Assistance Amounts

SAMS does not allow the Basic Assistance amount to be overridden to $0.00.

When a Program Eligibility override of $0.00 had been used in SDMT to override Basic Assistance, the $0.00 override converted into SAMS, however, SAMS issued the full amount of Basic Assistance as calculated by the system.

This impacts the following SDMT eligibility types:


• Ontario Works – Basic Needs• Ontario Works – Board and Lodge • Ontario Works – Personal Needs • ODSP – Basic Needs • ODSP – Board and Lodge • ODSP – Personal Needs • ACSD Financial Assistance• Temporary Care Assistance• Emergency Assistance – Basic Needs Allowance• Emergency Assistance – Board and Lodge

Note that this does not apply if the override was used to issue an extension of benefits (EHB, EEHB, or THB). In this scenario, Extension evidence will exist on the case.

6. Overpayments

i. Converted Overpayments

On the Product Delivery case, converted overpayments are not found on the Over and Under Payments Panel on the Financials Tab.


All converted Overpayments are found on the Related Case panel under the Case Details Tab.

However, all Liabilities can also be found at the Integrated Case level and Person level under the financial tabs.

Product Delivery Case Level: All Converted Overpayments are found on the Related Case Panel under the Case Details Tab.

Integrated Case Level: Liabilities (Overpayments) in SAMS can be found at the Integrated Case Level under the Financials Tab.


Person Case Level: Liabilities (Overpayments) in SAMS can be found at the Person Case Level under the Financials Tab.

ii. Reactivation of Written off SDMT Overpayments


Reactivation of a written off overpayment will require the user to create a manually adjusted overpayment. All converted O/Ps that are eligible for reactivation have been converted into an open status with an outstanding balance of $0.00.

iii. SDMT Terminated Cases with Overpayments

SDMT Terminated cases (prior to January 1, 2013) with overpayments converted to SAMS. The only details converted are; the Integrated Case, the person information and the overpayment case. No other details converted.

iv. Referring a Converted Overpayment to the Overpayment Recovery Unit (ORU)

If a new referral to the ORU is required for a SDMT converted overpayment and there is no Product Delivery Case on the Integrated Case, a new Product Delivery Case must be created.

A PDC can be created by creating an application within the integrated case.


7. Additional Benefits

i. Benefits in Requested State

Any one-time Additional Benefits for a benefit month of October 2014 or earlier which are in a requested status converted as 'In Edit' evidence in SAMS, and will require Activation or Cancellation (Apply Changes to the ‘In Edit’ Changes). This is true whether or not the SDMT benefit has a Release Date populated.

If a benefit was an ongoing benefit, or was for a benefit of November 2014 or later, no action was required. These benefits are paid during the monthly pay run as per regular business process.


ii. SDMT Release Date

The SDMT Release Date was not converted.

An SDMT benefit converted into SAMS was paid depending on the combination of benefit month and the SDMT Frequency:

• If a benefit was an Ongoing benefit in SDMT, regardless of the benefit month, no action will be required. These benefits are paid during the monthly pay run as per regular business process.

• If a benefit was a Onetime benefit in SDMT with a benefit month of October 2014 or earlier, it converted as ‘In Edit’ evidence and requires Activation or Cancellation.Once the benefit has been activated, it will be automatically paid at the time the benefit is activated, as per the process.

• If a benefit was an OW Onetime benefit in SDMT with a benefit month of November 2014 or later, action may have been required. These benefits would be paid overnight by SAMS as per regular business process.

8. Outcome Plans

i. Participation Agreement Conversion

A shell Outcome Plan was created for each member with Participation requirements.

Outcome plans exist for all OW members over the age of 18, and for younger members if they are an applicant or spouse, regardless of whether or not there was a Participation Agreement (PA) in SDMT. This was done in order to meet the mandatory SAMS rule requirement that an Outcome Plan must exist.

For members who had a PA in SDMT, this outcome plan converted to SAMS but will not contain any details from SDMT except the SDMT Next Review Date. As part of the conversion process, an “Initial Assessment” was created and the Participation Agreement was marked as “complete”.

The SAMS Participation Agreement, created by conversion, does not contain any ‘Activities’.

If the SDMT Next Review Date was prior to the conversion date, or if no PA existed in SDMT for a member, the Outcome Plan has a review date of the 'go live' date plus six months (May 2015). If the SDMT Next Review Date is after the conversion date, the


Outcome Plan will have a review date equal to the Next Review Date found in the SDMT.

9. Assistance for Children with Severe Disabilities (ACSD)


i. Child Information Evidence

At conversion, a child information evidence record was created for each SDMT ‘Member Details’ page that meets the following criteria:

• the Member Role is “Dependent Child” • the Program is “ACSD”• the Disabled checkbox is populated for the child

The household member, start date and end date (where applicable) are the only fields that populated with converted information and “CONVERSION” was populated in the comment section.

The start date and end dates populated based on the start date on the Member Program section of the SDMT ‘Member Details’ page.


Child Information evidence was not created if the member was not “Active” on the benefit unit on or after January 1, 2013.

ii. ACSD Family Count Evidence

At conversion, an ACSD Family Count Evidence record was created on the recipient’s integrated case in SAMS for cases where the “Program” on the SDMT ‘Member Details’


page is ACSD. The Benefit Unit Status must have been Screening, Verification, or Ongoing.

The family count number converted from the SDMT “ACSD Family Count” field on the SDMT ‘Member Details’ page. The start date and end dates populated based on the start and end date(s) on the Member Program section of the SDMT ‘Member Details page’.


iii. Specialized Child Expenses

At conversion, a Specialized Child Expenses evidence record was created for each expense record on the SDMT ‘Income & Expense List’ where the Expense Type is “Expenses - ACSD Total”.

The required evidence record fields populated as below:

SAMS field Information SourceStart date Start Date on the SDMT ‘Income &

Expense Details’ pageEnd date (if applicable) End Date on the SDMT ‘Income &

Expense Details’ pageHousehold member Member on the SDMT ‘Income &

Expense Details’ pageOther Expense Details “TOTAL ACSD EXPENSES PER

CONVERSION” will be populated in this field

Approved Amount Monthly Gross amount on SDMT ‘Income & Expense Detail’s page. If the SDMT amount is zero or a negative amount, the converted amount will default to


$0.00Expense Type Will default to “Other Expenses”.Frequency Will default to “Monthly”.Comments Will default to CONVERSION.

A Specialized Child Expenses evidence record was not created if the SDMT Income Record End Date was earlier than January 1, 2013.

iv. Taxed Income Evidence

At conversion, a Taxed Income evidence record was created for each income record on the SDMT ‘Income & Expense Detail’ page where the income type was ACSD Income.


The required evidence record fields were populated as below:

SAMS field Information SourceHousehold member The member on the SDMT Income &

Expense Details page.Type Will default to “Actual”Taxed Income The amount from the Monthly Gross

Amount on the SDMT ‘Income & Expense Details’ page multiplied by 12 to create an annual income amount. If the SDMT Monthly Gross Amount is zero or a negative amount, it will be converted as $0.00.

Tax Period Start Date The start date on the SDMT ‘Income & Expense Detail’ page.

Tax Period End Date The end date on the SDMT ‘Income & Expense Detail’ page.

Comments “CONVERSION” will be populated in this field.

A Taxed Income evidence record was not created if the income record end date was less than January 1, 2013.


10. Tips and Tricks for Working with Converted Data

i. What does Baseline Eligibility mean?

When cases were converted into SAMS, all of the information from SDMT was put into the relevant pages in SAMS. After that, SAMS performed a calculation of the amount the client was eligible for each month based on the converted information. This is what we call Baseline Eligibility.

The Baseline Eligibility Amount is the amount that SAMS “thinks” the client was paid for each month prior to conversion.

Baseline Eligibility exists for all cases, including the main Product Delivery cases (Ontario Works, ODSP, ACSD, and Temporary Care), as well as Additional Benefits, and Liability (Overpayment) cases.

The SAMS calculated Baseline Eligibility may match the amount paid in SDMT, or it may not. Mismatches in eligibility between SDMT and SAMS may have occurred for a couple of reasons: (1) some of the information from SDMT may not have matched properly with the equivalent fields in SAMS, (2) some of the rules in SAMS are different than the rules in SDMT, or (3) some of the SDMT data did not convert properly into SAMS.

The following are some terms used when the SAMS Baseline Eligibility amount does not match SDMT.


ii. No Baseline Amount

To have no Baseline Amount means that SAMS “thinks” that the case is ineligible. These cases may also be referred to as having a ‘Not Eligible Decision’.

On these cases, you will see dates in the Determinations tab, however the decision will display as “Not Eligible” for all periods.

Under this scenario, SAMS “thinks” that the client was never paid in SDMT.

To prevent underpayments and overpayments from being created in the future when data fixes and system upgrades occur, all converted Product Delivery and Additional Benefit cases that have no baseline eligibility amount, have been changed to “Suspended” status.

Instructions have been provided at the end of this document for properly closing cases that have no baseline eligibility amount and have been changed to “Suspended” status.

If the case requires activation, or if the client reapplies for assistance, do not use the existing “Suspended” Product Delivery or Additional Benefit case with no baseline amount. A new case should be created for the client to ensure that future underpayments and overpayments are not created as a result of the case not being base lined.

iii. Cases that did not Baseline

In some instances, SAMS may not have been able to determine eligibility for a case.

On these cases, you will not see any dates in the Determinations tab.


Under this scenario, SAMS “thinks” that the client was never paid in SDMT.

To prevent underpayments and overpayments from being created in the future when data fixes and system upgrades occur, all converted Product Delivery and Additional Benefit cases that did not baseline have been changed to “Suspended” status.

Instructions have been provided at the end of this document for properly closing cases that did not baseline and have been changed to “Suspended” status.


iv. Incorrect Baseline Amount

An Incorrect Baseline Amount can occur in situations where the amount that SAMS “thinks” the client was paid does not match the amount that the client was “actually” paid in SDMT. This could occur for as long as the entire history of the case, or for as short as a single month.

For these cases, you will see dates in the Product Delivery case Determinations tab; however the corresponding amounts may not match the amount of eligibility determined in SDMT.

Alternatively, the decision may display as “Not Eligible” for some periods that the case was eligible in SDMT, or it may display as “Eligible” for some periods that the case was ineligible in SDMT.


v. Baseline Overpayment and Baseline Underpayments / Arrears


If a change was made on the case that had an incorrect Baseline Eligibility, overpayments or underpayments (arrears) may be created strictly because of the incorrect Baseline amount.

When a change takes place and eligibility is reassessed on a case, SAMS compares the new eligibility amount with the amount that the client was paid.

If there was an incorrect Baseline Eligibility Amount (the amount that SAMS “thinks” the client is paid is different from the amount that the client was actually paid), any changes or corrections on a case that would normally not impact entitlement may trigger invalid overpayments or underpayments. These are called baseline overpayments or baseline underpayments. These overpayments or underpayments may occur as a result of changes that should not impact eligibility for a historical period, such as correcting a client’s primary address.

Baseline overpayments / underpayments may also occur on Additional Benefits (AB) that has an incorrect Baseline Eligibility, especially if the main Product Delivery case also had an incorrect Baseline Eligibility.

For example, if an Ontario Works case with associated Additional Benefits cases were all determined ineligible at conversion because the client was not converted with a primary address, the OW and AB cases would have no Baseline Eligibility. Once the primary address is corrected, the OW case will be reassessed by SAMS and a ‘Baseline’ underpayment will be generated for the full amount of assistance paid to the client between the grant date and the reassessment date. Also, once the OW case becomes eligible, the AB cases will also become eligible. An additional ‘Baseline’ underpayment will be generated for the full amount of additional benefits paid to the client between the additional benefit start date and the reassessment date.Understanding why there are Multiple Product Delivery Cases

vi. Understanding Why there are Multiple Product Delivery Cases

In SAMS, when there is a break in assistance and the client returns to the program, changes are made to the Integrated Case and reflected on the Product Delivery Case


Determinations page. This is similar to the Benefit Unit History section in SDMT where you will see breaks in assistance.

For converted cases, each time there was a break in assistance in SDMT for the case, a distinct Product Delivery Case would have been converted into SAMS for each period of time that the case was ongoing in SDMT. Note that a Product Delivery Case would have only been converted into SAMS if the case was ongoing in SDMT for a time period on or after January 1, 2013.

The following example compares a case in SDMT and SAMS.

vii. Where to Find SDMT and SAMS Eligibility Amounts

Information from the Program Eligibility List page of SDMT was converted into SAMS. The Program Eligibility Details can be found in SAMS within the Determinations tab of the Product Delivery Case. To see the SDMT calculated entitlement for a particular


month, you may hyperlink into the applicable benefit period, and click on the SDMT Information tab. When modifying a case for a converted period, it is recommended that staff always compare the SAMS eligibility amount to the SDMT eligibility amount prior to making any changes.

The Baseline Eligibility amount that SAMS calculated at the time of conversion (the amount SAMS “thinks” the client was paid) can be seen in SAMS. Go to the Determination History section and find the determination record with a Reason of “Case Activation” and a date between November 7 and November 10, 2014.

If there is no Baseline Eligibility (there is no determination record with a date of November 7, 2014), SAMS “thinks” that the client did not receive any payments in SDMT.

Each time a change is applied on an Integrated Case, SAMS recalculates entitlement for the Product Delivery cases associated with it. The new eligibility amount is


compared with the amounts the client was paid and the system will determine if any overpayments or underpayments are required.

If there was an incorrect Baseline Eligibility Amount, invalid overpayments or underpayments may result. This is because the amount that SAMS “thinks” the client is paid is different from the amount that the client was actually paid.

viii. Where to find SDMT and SAMS Payment Information

Payment information that existed in SDMT was converted into SAMS. These payments can be found in the following locations:

• Financials tab on any of the Product Delivery Case• Financials tab on the Integrated Case• Financial tab on the Person page

Integrated Case Financials Tab

All payments made on behalf of any Product Delivery Case or Additional Benefit case within the Integrated Case will appear in this tab. This includes monthly assistance amounts, payments made to vendors or third parties, additional benefit payments, liabilities (overpayments), and underpayments (arrears).

Payments made on Product Delivery Cases or Additional Benefits cases belonging to other Integrated Cases will not appear, even if those payments were made to the primary client.

Product Delivery Case Financials Tab

All payments made on behalf of the Product Delivery case will appear in this tab. This includes monthly assistance amounts, direct deposit payments made to third parties, liabilities (overpayments), and underpayments (arrears).

Any payments made on other Product Delivery cases (such as Additional Benefit Cases) will not appear in this tab. Additional Benefit payments will only appear if the Additional Benefit amount is within the PDC payment (such as when Medical Travel benefits are included in monthly assistance payment).

Person Financial Tab

All payments made to the Person, or overpayments created for the Person, will appear in this tab. This includes monthly assistance amounts, additional benefit payments, liabilities (overpayments), and underpayments (arrears).


Payments made to other individuals will not appear here, even if those payments were made on behalf of the Person (such as direct deposit payments). See the “Comparing SAMS and SDMT Payments” section below for an example of where a payment to a vendor would appear.

Additional Benefit case Financial Tab

All payments made on behalf of the Additional Benefit case will appear in this tab.

Any payments made on other Additional Benefit cases or on the Product Delivery cases will not appear in this tab. Payments for other Additional Benefits or Product Delivery cases will only appear if the Additional Benefit amount is within the AB or PDC payment (such as when Medical Travel benefits are included in monthly assistance payment).

Comparing SAMS and SDMT Payments

These SAMS Financials pages are very much like the SDMT Payments List page. In SDMT, you would click into the payment and it would display all of the payment information, as well as the individual benefit amounts that made up the total payment amount. In SAMS, you will use the drop down toggle arrow to expand the record and display all of the payment information, as well as the individual benefit amounts (payment items) that made up the payment.

SAMS shows more information than SDMT for the individual benefit (payment item) amounts that make up the total payment amount:

Case ID. This will show the Product Delivery case, Additional Benefit case, Liability case, or Overpayment case that triggered the payment item amount.

Cover Period. This will tell you which month(s) the individual payment item amount was generated for.

Debit or Credit. Each payment amount will show whether it is a debit or a credit. Credits are amounts that are added to increase the total payment amount. Debits are amounts that are subtracted to decrease the total payment amount.

Note that, when you use the drop down toggle arrow to expand the record and display all of the payment information, the amount displayed in the payment information section may not match the amount in the search results summary line. This will occur when the payment is made to a third party or trustee. The amount in the search summary line results represents the total cheque amount made to the third party or trustee. The amount displayed within the expanded record represents the portion of the payment that was made on behalf of the integrated case you are looking at.

For example, a payment was made to a pharmacy. The total payment was $45 and was made up of medical devices costing $15 each which were purchased for 3 separate clients.


On the Person page for the Pharmacy, you will see a payment of $45 with 3 payment items

On the Integrated Case for each client, you will see a payment summary of $45 to the Pharmacy, but when you toggle into the payment, you will see details of only $15 which is the amount applicable to that client.

Payment Instrument History

For every payment, there is a Payment Instrument History. This will be visible when you toggle open the payment record and go down to the bottom of the expanded record.

By selecting the arrow on the right side of the screen you can open the history to see whether the payment has been issued.

Compare the SDMT Entitlement Amount to the SAMS Entitlement Amount.

When working with data in the converted period, always check the SDMT Entitlement Amount against the SAMS Entitlement amount to ensure they are the same for the months impacted by the changes. If they are not the same, it is likely that baseline overpayments or underpayments will be created once the changes are applied.

ix. Important Tips When Making Changes on a Case

Compare the SDMT Entitlement Amount to the SAMS Entitlement Amount

When working with data in the converted period, always check the SDMT Entitlement Amount against the SAMS Entitlement amount to ensure they are the same for the months impacted by the changes. If they are not the same, it is likely that baseline overpayments or underpayments will be created once the changes are applied.

Check for Override Evidence

Always check for override evidence before making a change for which a change in entitlement is anticipated. Override evidence takes precedence over all other evidence, so if you’re making a change to shelter or other evidence, you may not see the change reflected in the eligibility determination if an override evidence exists for that benefit type.


Make Changes One at a Time and Check for New Overpayments and Underpayments

When multiple changes are required on a case, apply the changes one at a time. This makes it easier to determine which specific change triggered an overpayment or underpayment.

If the change should not have resulted in an overpayment or underpayment, it may be a baseline overpayment or underpayment. Applying changes one at a time makes it easier to pinpoint any amounts resulting from Baseline overpayment / underpayment that should be cancelled.

Unexpected Entitlement Amounts

If the entitlement amount is not what you expect, go to the Product Delivery case Determinations tab and hyperlink into the record for the determination period. Go through all of the tabs and sections within the determination record.

The tabs provide information about how SAMS calculated the eligibility and the entitlement amount; which household members were included in (or excluded from) the calculation, the shelter and utility amounts used to determine the shelter entitlement, the income used to determine the income deduction, and the assets used to determine whether the case is eligible based on the asset exemption amount.

Arrears Payments for the Conversion Period

When reassessment occurs in SAMS and a payment is generated, if any portion of the payment includes arrears for the conversion period (any time between January 1, 2013 and October 31, 2014), that payment will automatically be suspended.

Staff will be required to review the composition of these payments, and determine whether the entire payment, or any portion of it, should be released to the client. If any portion is invalid, that portion should be cancelled.

Consider the following examples:

1) A payment was generated and covers the period of March – June 2014.2) This payment would be suspended automatically (the cover period includes

conversion months).3) A payment was generated and covers the period of August – December 2014.4) This payment would be suspended automatically (the cover period includes

conversion months).5) A payment was generated and covers the period of November – December 2014.6) This payment would not be suspended (it does not include any conversion

months).


If it has been determined that the payment has some portion that is valid, and a portion that is invalid, a manual overpayment and a corresponding applied deduction may be required to separate the inappropriate amount from the portion that is actually owing to the client.

Converted Cases that did not Baseline, or have No Baseline Eligibility

To prevent underpayments and overpayments from being created in the future when data fixes and system upgrades occur, all converted Product Delivery and Additional Benefit cases that did not baseline, or have no baseline eligibility amount, have been changed to “Suspended” status.

Instructions have been provided at the end of this document for properly closing cases that did not baseline, or have no baseline eligibility amount, and have been changed to “Suspended” status.


Cases Stuck in “Open” Status – Updated March 2015

There are instances where a case has a status of Òpen’ or Àpproved’ and cannot be changed to Àctive’. The case appears to be stuck in the Òpen’ or Àpproved’ status. Note that an error message may or may not be occurring in these situations.

To activate these cases, follow the instructions in the following communication: SAMS Communication Update 86: “Unhandled Server Exception" message may occur when users are attempting to apply changes.

x. Investigating SAMS Overpayments and Underpayments

When overpayments or underpayments are created in SAMS, users must determine whether these amounts are owed by the client or owed to the client, or if these overpayments / underpayments are invalid. For further details, refer to the User guide Understanding and Reviewing Overpayments.

xi. Product Delivery Cases Suspended Because of Baseline Errors


https://www.samo.css.gov.on.ca/ld/sams/documents/SAMSUserGuide/new/reviewing-overpayments.docx

https://www.samo.css.gov.on.ca/ld/sams/documents/SAMSUserGuide/Communication/SAMS%20Communication%20Update%2086%20-%20Unhandled%20Server%20Exception%20message%20when%20applying%20changes.doc



There were converted Product Delivery Cases which did not have an eligibility baseline (i.e. no baseline amount or no baseline eligibility). To prevent underpayments and overpayments from being created in the future when data fixes and system upgrades occur, all converted Product Delivery Cases that did not baseline were changed to “Suspended” status. This was done because cases in Suspended status will not produce payments, as opposed to cases in Active or Closed status which will produce payments.

Previously, instructions were given that the suspension should never be removed from these PDCs, since doing so would potentially allow unexpected arrears payments and overpayments to generate for historical periods.

However, because of these suspended PDCs, new applications are not able to be activated for clients who are involved in one of these suspended PDCs. Also, the suspended PDCs are causing confusion when there are multiple PDCs within the Integrated Case.

To correct this issue, and allow new Product Delivery Cases to be Activated, the steps below should be followed in order to correctly remove the suspension from the converted PDC by first creating a deemed income charge. The deemed income is used to ensure the converted case does not become eligible in the future (and subsequently produce invalid arrears) when data fixes and system upgrades occur.

Identifying if the Product Delivery Case is Suspended for Baseline Errors

The steps below should only be followed if a Product Delivery Case or Additional Benefit Case was converted from SDMT, the case is in a Suspended status, and the Suspension reason is ‘Converted case that wasn’t Eligible”.

In addition, one of the following two situations will also exist:

There is no conversion Baseline Amount

In the Current Determination section of the Product Delivery Case, there are records in the Determination Results, however the decision will display as “Not Eligible” for all coverage periods.


There is no Baseline Eligibility Decision

In the Current Determination section of the Product Delivery Case, there are ‘No Decisions Available’, along with a message that “Eligibility must first be determined in order to be able to view Decision information”.

Steps for Closing Baseline Error Suspended Product Delivery Cases

If it has been determined that the Product Delivery Case is Suspended because of Baseline errors and the case requires activation, or if the client reapplies for assistance, do not use the existing “Suspended” Product Delivery Case with no baseline amount. A new case should be created for the client to ensure that future underpayments and overpayments are not created as a result of the case not being base lined.

To close the suspended case, follow the steps below to create a deemed income charge which will ensure that unexpected arrears payments and overpayments to generate for historical periods.

Alternatively, if there is an Active (ongoing) Product Delivery Case in addition to a PDC that is suspended because of Baseline errors, the steps below can be followed to avoid any confusion associated with the existence of the suspended PDC.

The steps below can be taken for each Ontario Works or ODSP Product Delivery Case that meets the conditions of being suspended for baseline errors.


Find the original case dates associated with the suspended PDC.

1. From the Product Delivery Case, look in the Case Status section of the Administration Tab.

2. Identify the record where the Status is ‘Active’ and the comments are ‘CONVERSION’.

Note: there should also be a record with a Status of ‘Suspended’ and comments of ‘CONVERSION’.

3. Make note of the ‘From’ and ‘To’ dates for the record with the Status of Active, as these dates will be used in subsequent steps.

4. If there’s any confusion, the date information can be confirmed by going into the Benefit Unit History section in SDMT. Select the ‘Program’ and the ‘All’ radial buttons, and click Search.

5. From the results, identify the record where the case Status was ‘Ongoing’ and the record Start Date matches the Suspended PDC Start Date in SAMS.


Add a deemed income charge for the duration of the suspended case.

6. From the Integrated Case, create a new Unearned Income evidence, populated with the following information:

• Participant: select the Primary client.• Unearned Income Type: select ‘Other Income’.• Amount: 99,999.00.• Frequency: select ‘Monthly’.• Start Date: use the ‘From’ date obtained in step #3.• End Date: use the earlier of the following two dates, depending on the

program type:ODSP: either the ‘To’ date obtained in step #3 or September 30, 2014.OW: either the ‘To’ date obtained in step #3 or September 15, 2014.

• Last Payment Date: use the earlier of the following two dates, depending on the program type:ODSP: either the ‘To’ date obtained in step #3 or September 30, 2014.OW: either the ‘To’ date obtained in step #3 or September 15, 2014.

• Comments: “Data Conversion Baseline Errors – Deemed Income Charge Applied.”

7. Apply the evidence changes on the Integrated Case.

Remove the Suspension from the Product Delivery Case.

8. On the suspended Product Delivery Case, remove the Suspension.


• Suspend Reason: New Evidence.• Comments: “Data Conversion Baseline Errors – Deemed Income Charge

Applied”.

Close the Product Delivery Case.

9. Close the Product Delivery Case.

Closure Date: use the earlier of the following two dates, depending on the program type:

ODSP: either the ‘To’ date obtained in step #3 or October 31, 2014. OW: either the ‘To’ date obtained in step #3 or November 30, 2014.• Reason: select ‘Active in another case or program’.• Comments: “Data Conversion Baseline Errors – Deemed Income Charge

Applied”.

Notes on Creating the New Product Delivery Case Application

If staff identify that a client should be eligible for assistance and the most recent case for the client is one of the suspended cases with a reason of ‘Converted case that wasn’t Eligible’, staff must create a new Integrated Case by creating an Application from the Person Page in order to activate a new Main Product Delivery case.

The converted evidence must not be merged with the new Integrated Case. This evidence may cause the same error as in the original case.


Staff must recreate the original evidence records to create the appropriate entitlement for the client.

The start date of the new Product Delivery Case should be determined based on the period that client should be eligible for, going forward. For example if you wish to issue Ontario Works benefits for the month of November forward, the case start date must be November 1, 2014.

11. Updating Secondary Contributors

As part of data conversion cleanup, clients in a co-residency situation (only paying part of a larger rental amount) required some manual cleanup of their evidence. In these instances, the shelter or utility parent evidence would be for the amount paid by the client instead of the total rental/utility amount. Edits to the shelter, contributor and living arrangement evidence could not be made until this is managed.


This data can be corrected on a “touch-the-file” basis as it does not impact the client’s eligibility

Example:

Notice in the screenshot below that the converted client has a second contributor (Fake Contributor 17) who is listed as a paying $0.00 of the rent. The client is listed as paying $350.00. The example below references Shelter Expense Evidence. The same steps would be followed in the case of Utility Expense Evidence.

Cleanup will require one of two options: (Option A is used in this example).

Option AUser will maintain the secondary contributor’s record in SAMS.

i. Correcting the amount paid by the “Fake Contributor #” in the related contributor record

ii. Correcting the total shelter/utility amount identified in the related shelter record

iii. Applying changesiv. Updating the name of the “Fake Contributor”(optional)


Option BUser will delete the secondary contributor’s record in SAMS (client’s portion will be considered the full shelter expense).

Preliminary steps:

• The user has noted the existence of a “Fake Contributor” paying $0.00 while noting a shelter payment for more than $0.01. The user should also be aware of the amount paid by the sharer.

• The full shelter amount must be known by the user (e.g. from SDMT)• The name of the other person sharing rent with the client must be known.

When navigating the tabs necessary to update the evidence, a specific path should be used in order to clearly identify the linked parent-child evidence.

• Access the IC (A)• Access the Shelter Expense evidence from the dashboard. (B)• Select the link displayed in the Description column.(C)• Select the Contributor sub-tab. (D)

The amount listed in the Contributor sub-tab displays all contributors associated with the related shelter amount.

• Select the link for the Fake Contributor (A) and select to expand the details.• Select Edit. (B)

• Enter the actual amount paid by the secondary contributor in the Expense Amount field. (A)


• Select Save. (B)

• Select the corresponding Shelter Expense.• Select for the related shelter amount. (A) • Select and select Edit. (B)

• Enter the FULL amount paid by the household in the Total Expense Amount field. (A)


• Select Save. (B)

• From the IC, Select Apply Changes. Select the new evidence, confirm the amounts are in sync with your existing (applied) evidence and Save.

If you need to update the name of the secondary contributor, continue with the steps below:

• From the IC, select the Case Details tab. (A)• Select Case Participants from the side menu. (B)• Select the Fake Contributer # link displayed as a Contributor. (C)• Select and select Edit. (D)


• Select Actions and select Edit.

Enter the name of the secondary contributor. (A) Select Save. (B)

The shelter and contributor evidence have been updated with their correct amounts. You are also able to edit living arrangement evidence as needed. The client’s eligibility is not impacted as the individual contributor amount has not been changed.

12. Converted Disability Type Evidence for ODSP

In some situations the Disability Type on converted ODSP cases in SAMS did not reflect the actual Reason for Applying in SDMT.

In SAMS, the Disability Type for members was converted using the ‘Reason for Applying’ from the Member Details page of the Benefit Unit.


If the reason for applying changed in SDMT, the change was not captured by conversion to determine the member’s disability type. As a result, the earliest ‘Reason for Applying’ was converted.

For example; In SAMS, if the SDMT initial ‘Reason for Applying’ changed from “ODSP- CPP-Disability” to a different ODSP application reason, the Disability Type of “CPP-D” was populated.

The Disability Type must be corrected in SAMS to reflect the accurate reason for applying.

Procedure to Correct the Disability Type in SAMS

Disabled BU member is the Applicant: this table contains the disability types that should be used for SAMS with the corresponding disability type in SDMT.

SDMT Values SAMS ValuesODSP - Aged (65 and Over) 65 years of age - ineligible for OASODSP- CPP-Disability * CPP – D1

FBA - Grandparented (cc 01-06)

Grand parented FBA

FBA - Grandparented (SSP)

Grand parented FBA

FBA-Grandparent Psych Patient

Grand parented FBA

For all other SDMT Values Adjudicated - Disabled

* If the Disability Determination Evidence type is CPP-D there must be CPP-D income evidence or the case will be considered non-compliant.

Disabled BU member is the Spouse: this table contains the disability types that should be used for SAMS for the corresponding disability type in SDMT.

SDMT Values SAMS ValuesODSP - Aged (65 and Over) 65 years of age - ineligible for OASODSP- CPP-Disability CPP – D1

FBA - Grandparented (cc 01-06)

FBA grand parented blind, disabled or permanently unemployable

FBA - Grandparented (SSP)


FBA-Grandparent Psych Patient


For all other SDMT Values Adjudicated - Disabled


* If the Disability Determination Evidence type is CPP-D there must be CPP-D income evidence or the case will be considered non-compliant.

i. Update the Disability Determination Type

In SDMT, determine the current ‘Reason for Applying’ for the case. This reason will be used to populate the SAMS Disability Determination Type.

• Navigate to the Integrated Case – Evidence Dashboard.• Select the Disability Determination evidence (in the Household section)• Identify the current record for the member and select toggle drop down

arrow to expand the record.• Select and select Edit.• Change the Disability Type to the appropriate reason, using the current

‘Reason for Applying’ from SDMT.• Populate the Effective Date of Change with the current date.• Select Save.• From the Evidence Dashboard on the Integrated Case, Select and

select Apply Changes.

ii. Review/Cancel the Letter

• Navigate to the Case Details tab on the Product Delivery Case.• Select Communications in the left side bar.• Identify if there is a letter with the current date created because of this

change. Select and select Cancel.

iii. Modify Payment Type

When SAMS reassesses the case after the disability type is updated, there is a chance that arrears may be issued to the member. The arrears payment should be suppressed if the member has already received the payment in SDMT or SAMS. Refer to User guide Changing an Issued Payment.

13. Two Converted ODSP PDCs

At the time of conversion, SAMS converted 2 ODSP PDCs from SDMT. This appears to be common with Trustee cases.


https://www.samo.css.gov.on.ca/ld/sams/documents/SAMSUserGuide/new/changing-issued-payments.docx

Solution:

If it has been determined that SAMS converted 2 PDCs for the same client, the user must suspend the Active “good” PDC prior to proceeding. It is not possible to have two active PDCs at the same time in SAMS.

• Review the Active “good” PDC start date, verify the grant date is correct.• Select Actions and Suspend the file (select the most appropriate reason).• Suspension Date: select the last day of the month for which the client has

received a payment (i.e. 31/01/2016 since today is 08/02/2016).• From the Cases tab, select the 2nd converted Suspended PDC.• Select Actions and Unsuspend.• From the Suspend Reason screen, select New Evidence.• Add comments “Data Conversion Error”.• Select Actions and Close the Case.

Remember to Activate the “good” PDC.Delete any communications pertaining to this transaction.


Documents

· Web view2016. 3. 24. · SAMS is designed very differently from SDMT. SAMS is a rule based system which can store additional and more detailed information than SDMT. There are