Client Index Training Presentation
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Client Index Training Presentation

  • 819 views
Uploaded on

Training presentation on the Client Index used to uniquely identify clients of Health and Human Services in the County of Marin.

Training presentation on the Client Index used to uniquely identify clients of Health and Human Services in the County of Marin.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
819
On Slideshare
816
From Embeds
3
Number of Embeds
1

Actions

Shares
Downloads
3
Comments
0
Likes
0

Embeds 3

http://www.linkedin.com 3

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. H&HS Client Index Fred A. Kilby Senior Systems Support Analyst
  • 2. The Problem
    • “ Health & Human Services has more than 30 systems that contain client data, as well as information pertaining to the client’s involvements with each program. The systems range from small Access database applications to large, mainframe, state-mandated systems. For the most part, these systems do not communicate with each other, making unique identification of clients impossible. It is a goal of H&HS to be able to identify unique clients, populations served, and co-registration among departmental programs and services. “
      • (Project Proposal – 2. Problem Statement)
  • 3. The Solution
    • The creation of a master client index to uniquely identify all clients receiving services provided by H&HS:
      • to provide an indicator of which programs have had contact with the client
      • to provide an accurate, unduplicated listing of clients across all the programs of H&HS
      • to afford statistical reporting capabilities on services furnished.
  • 4. The Features
    • A consistent view of disparate demographic and client information across systems.
      • Names
      • Gender
      • Social Security Number
      • Ethnicity
      • Date of Birth
    • Ability to search for clients
      • By name,
      • By Social Security Number
      • By Date of Birth
      • By State Client Index
  • 5. The Features
    • Display of activities for each client
      • Begin and End Dates
      • Contacts
    • Reports of distribution of clients
      • Location
      • Ethnicity
      • Gender
      • Marital status
      • Age
    • Browser access to the application through the County of Marin Internet, using secured connection with SSL (https)
  • 6. Where We Get The Data
    • Data comes from the H&HS Systems
      • InSyst
      • State Automated Welfare System
      • Senior Assistance Management System
      • California Medical Management System
      • Case Management Information and Payroll System
      • Financial Accounting System
      • And many more
  • 7. How We Get Data
    • Access databases
    • Text files
    • Mainframe Extracts
    • CD-ROM
    • Other
  • 8. How We Get Data
  • 9. How We Transform Data
    • Objective
    • To provide “reporting and analysis capability that, at a minimum, permits accurate and easy quantification of unique clients, and a broad view of client demographics across the department.”
          • Business Requirements 1.3 Objectives, #3
  • 10. Design
    • To accomplish this objective this system established a coding scheme to represent specific demographic data.
    • Based on well known standards
      • United States Census Bureau
      • United States Postal Service
      • International Standard Organization
  • 11. Design
    • Based on DP-1. Profile of General Demographic Characteristics
  • 12. Code Driven Data
    • Ethnicity/Race
    • Hispanic Origin
    • Country
    • Language
    • State
    • Disability
    • Marital Status
    • Education
  • 13. Ethnicity/Race
    • The Client Index will use the ethnicity codes as defined by the US Census Bureau.
      • http://www.census.gov/acs/www/UseData/Def/Race.htm
      • These categories are socio-political constructs and should not be interpreted as being scientific or anthropological in nature. Furthermore, the race categories include both racial and national origin groups.
  • 14. Ethnicity/Race
    • The racial classifications used by the Census Bureau adhere to the October 30, 1997 Federal Register Notice entitled, "Revisions to the Standards for the Classification of Federal Data on Race and Ethnicity" issued by the Office of Management and Budget (OMB). These standards govern the categories used to collect and present federal data on race and ethnicity.
  • 15. Ethnicity/Race The OMB race categories The Census question (600) Some Other Race (300) American Indian or Alaska Native (500) Native Hawaiian or Other Pacific Islander (200) Black or African American (400) Asian (100) White
  • 16. Ethnicity/Race
    • The Client Index will use these summary codes and source systems will be mapped appropriately.
  • 17. Ethnicity/Race
    • Using these codes the data in the Client Index can be compared to the US Census.
  • 18. Hispanic Origin
    • The federal government considers race and Hispanic origin to be two separate and distinct concepts.
    • Origin can be viewed as the heritage, nationality group, lineage, or country of birth of the person or the person’s parents or ancestors before their arrival in the United States. Persons of Hispanic origin may be of any race.
  • 19. Hispanic Origin
    • The Client Index will only use these summary codes and source system’s values will be mapped appropriately.
  • 20. Hispanic Origin
    • Using these codes the data in the Client Index can be used to evaluate population comparisons to the US Census.
  • 21. Country and Language Values
    • Country code values come from the International Standards Organization (ISO)
      • http://userpage.chemie.fu-berlin.de/diverse/doc/ISO_3166.html
      • 3 character coding system
      • Plus general codes for non-ISO codes (Asia General)
    • Language code values come from the ISO
      • http://www.oasis-open.org/cover/iso639a.html
      • System’s values will be mapped appropriately
  • 22. US States values
    • State code values come from the
    • United States Postal Service
      • http://www.usps.com/ncsc/lookups/usps_abbreviations. htm
  • 23. Disability Values
    • There are currently no “standards” for setting up values for disability.
    • The Client Index adopted values used by existing County systems.
  • 24. Marital Status Values
    • This is the code defining the marital status of a person.
    • The US Census has five classifications
        • Now Married, Widowed, Divorced Separated, Never Married.
    • The County contains a greater number of Classifications.
    • There are no “standard” formats
  • 25. Marital Status Values
    • A superset of marital classifications based on the County systems is used.
  • 26. Education / Degree Values
    • Education represents the level of education achieved and the attainment of a degree.
    • Not many systems track this.
    • Education Levels 1- 20 represents years.
    • Degree attainment:
  • 27. Example
    •   What is the racial makeup of clients that receive services from the Division of Mental Health and how does this compare in relation to the total County makeup?
  • 28. The Rules we apply
    • Objective
    • To provide reporting and analysis capability that, at a minimum, permits accurate and easy quantification of unique clients, and a broad view of client demographics across the department.
    • (Business Requirements For H&HS Client Index Project, 1.3 Objectives, #3)
  • 29. Translation Tables
    • Values from source systems are standardized
    • One value from a source system can become one or more values in the Index
    • Client Index Code Translation document contains translation methodology and values.
  • 30. Translation Rules
    • Invalid Values
    • Values that change
    • Values that are cumulative
    • Dependant Values
    • Names
  • 31. Invalid Values Rules
    • Invalid values will be replaced
      • If no value present an invalid one can be used.
        • SSN: 000-00-1234  Nothing
      • A valid new value will replace an invalid.
        • SSN: 987-12-4321  000-00-1234
      • An invalid value can not replace a valid one.
        • SSN: 000-00-1234 –x 987-12-3421
  • 32. Values that Change Rules
    • Specific values override generalized values
    • Specific values are considered equals
  • 33. Values that Change Rules
    • GENDER
      • Male/Female  Unknown
      • Unknown –x Male/Female
      • Male  Female
    • COUNTRY Of BIRTH
      • Germany (deu)  Europe (eux)
      • Europe (eux) –x Germany (deu)
      • Mexico (mex)  United States (usa)
  • 34. Values that Change Rules
    • Example of Specific Override
  • 35. Values that Change Rules
    • HISPANIC ORIGIN
      • Mexican  Other Hispanic
      • Other Hispanic –x Mexican
      • Mexican  Not Hispanic Origin
      • Not Hispanic  Mexican/Other Hispanic
    • MARITAL STATUS
    • EDUCATION / EDU DEGREE
    • PREFERRED LANGUAGE
    • STATE OF BIRTH
  • 36. Values that are Cumulative
    • RACE
      • Vietnamese (450)  Amerasian (649)
      • Amerasian (649) –x Vietnamese (450)
      • White (100) AND Vietnamese (450)
        • White/Vietnamese
    • DISABILITIES
      • Blind  Unknown
      • Unknown –x Blind
      • Blind AND Deaf
        • ( Blind/Deaf )
  • 37. Values that are Cumulative
    • Example of Cumulative
  • 38. Dependant Values
    • State Of Birth
      • If country of birth is not USA then state of birth must be ‘unknown‘
    • Education and Education Degree
      • If a Education Degree is set then an Education must be at least to a corresponding level
        • High School degree  Education level 12
        • Bachelors Degree  Education level 16
  • 39. Dependant Values
    • Example of Birth Place
  • 40. Names Rules
    • Rule 1:
        • A client can have only one name of each of the types "Client" and "Birth" and can have multiple names of the Type "Alias".
    • Rule 2:
        • During import process any new name with a type other than "Client" or "Birth" will be added as a type of "Alias".
  • 41. Names Rules
    • Rule 3:
        • There can not be duplicate name values for the type of "Alias" for the same client.
    • Rule 4:
        • The name with type of “Client” will reflect the most current begin activity date from any system.
  • 42. Names Rules
    • Rule 5:
        • When a name of the type “Client” is changed the old name will be changed to the type of “Alias”. Limited only by Rule 3.
    • Rule 6:
        • When a name of the type “Client” is changed due to activity begin date and the name already exists as an “Alias” the type of “Alias” will be removed.
  • 43. System Reports
    • Import Load Changes
    • Change Log Report
    • Import Exceptions
  • 44. Import Exceptions
    • This report provides information on errors and exceptions that occurred during the import process.
  • 45. Load Changes
    • This is a report of changes that have occurred during an import.
  • 46. Change Log
    • This is a report of changes that have occurred and includes definitions for code values.
  • 47. The Security
    • Security is implemented by presenting each division in H&HS as a distinct application.
    • Within the application definition, the security is further refined into role levels.
    • Each user can be assigned to one or more roles. Security access privileges will be assigned by H&HS
  • 48. The Security
    • CI_ALL
        • Access to all data for all departments
  • 49. The Security
    • CI_Reports
        • Access to Reports ONLY
  • 50. The Security
    • CI_ Div Access to non-detailed division activities
  • 51. The Security
    • CI_ Div _D Access to detailed division activities
  • 52. The Security
    • Mixed Levels
        • Access to some divisions detail activities and to non-detailed activities for other divisions
  • 53. How To Use The Client Index
    • Turn to Page 15
    • User Id: ci_all
    • Password: sesame
    • Search for Last Name ‘Kennedy’