H&HS Client Index

Fred A. Kilby

Senior Systems Support Analyst

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)

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.

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

The Features

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)

Display of activities for each client Begin and End Dates Contacts

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

How We Get Data

Access databases

Text files

Mainframe Extracts

CD-ROM

Other

How We Get Data

How We Transform Data

ObjectiveTo 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

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

Design

Based on DP-1. Profile of General Demographic Characteristics

Code Driven Data

Ethnicity/RaceHispanic OriginCountryLanguageStateDisabilityMarital StatusEducation

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.

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.

Ethnicity/Race

(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

The OMB race categories

The Census question

Ethnicity/Race

The Client Index will use these summary codes and source systems will be mapped appropriately.

Ethnicity/Race

Using these codes the data in the Client Index can be compared to the US Census.

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.

Hispanic Origin

The Client Index will only use these summary codes and source system’s values will be mapped appropriately.

Hispanic Origin

Using these codes the data in the Client Index can be used to evaluate population comparisons to the US Census.

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

US States values

State code values come from the

United States Postal Service http://www.usps.com/ncsc/lookups/usps_abbreviations.htm

Disability Values

There are currently no “standards” for setting up values for disability.

The Client Index adopted values used by existing County systems.

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

Marital Status Values

A superset of marital classifications based on the County systems is used.

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:

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?

The Rules we apply

ObjectiveTo 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)

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.

Translation Rules

Invalid ValuesValues that changeValues that are cumulativeDependant ValuesNames

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

Values that Change Rules

Specific values override generalized values

Specific values are considered equals

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)

Values that Change Rules

Example of Specific Override

Values that Change Rules

HISPANIC ORIGIN• Mexican Other Hispanic • Other Hispanic–x Mexican • Mexican Not Hispanic Origin• Not Hispanic Mexican/Other Hispanic

MARITAL STATUSEDUCATION / EDU DEGREEPREFERRED LANGUAGESTATE OF BIRTH

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 )

Values that are Cumulative

Example of Cumulative

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

Dependant Values

Example of Birth Place

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".

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.

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.

System Reports

Import Load Changes

Change Log Report

Import Exceptions

Import Exceptions

This report provides information on errors and exceptions that occurred during the import process.

Load Changes

This is a report of changes that have occurred during an import.

Change Log

This is a report of changes that have occurred and includes definitions for code values.

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

The Security

CI_ALL Access to all data for all departments

The Security

CI_ReportsAccess to Reports ONLY

The Security

CI_Div Access to non-detailed division activities

The Security

CI_Div_D Access to detailed division activities

The Security

Mixed LevelsAccess to some divisions detail activities and to non-detailed activities

for other divisions

How To Use The Client Index

Turn to Page 15

User Id: ci_allPassword: sesame

Search for Last Name ‘Kennedy’