Welcome to the Information Management approach page

Information Management

What is the difference between Data Management and Information Management?

Information Management is defined as a program that manages the people, processes and technology in an enterprise towards the control over the structure, processing, delivery and usage of information required for management and business intelligence purposes.

Information includes both electronic and physical information. The organizational structure must be capable of managing this information throughout the information lifecycle regardless of source or format (e.g., data, paper documents, electronic documents, audio, video, etc.) for delivery through multiple channels that may include cell phones and web interfaces.

Data Management is a subset of Information Management. It comprises all the disciplines related to managing data as a valuable resource. Data management is the process involved in creating, obtaining, transforming, sharing, protecting, documenting and preserving data. Source: http://www.b-eye-network.com/blogs/oneal/archives/2012/02/what_is_

What is Master Data Management?

This section includes material related to the Business analysis, Business Process modeling, and other business approach topics

Information Architecture Roadmap

Description: The Information Architecture Roadmap describes the tactical and strategic processes used to develop information management standards and models that support the characterization of CWS-NS data sources and the development of CWS-NS data and information models (e.g., conceptual data model, logical data model, data dictionary, and data governance).

CWS-NS Information Architecture Vision:

Definitive identification of all persons, providers, and facilities support child safety and a more efficient application. The CWS-NS Project envisions the use of master indexes and accompanying tools and capabilities to maintain distinct entities (e.g., persons, service providers, schools, and facilities) in CWS-NS. While the volume of client duplicates in CWS/CMS has been closely controlled due to its impact on state and federal reporting, other duplicate entities (e.g., service providers) represent both a significant portion of the required data cleansing identified by the CWS/CMS Data Quality Team and a significant challenge for counties and those conducting data conversion efforts. Therefore, a major goal of data management in CWS-NS is to provide capabilities to maximize the distinct identification of all entities and minimize the creation of duplicate records. These goals are achieved via an approach referred to as Master Data Management (MDM).

A MDM approach, comprised of the processes, governance, policies, standards and tools to manage the critical data of an organization, provide a single point-of-reference. For CWS-NS, the MDM focus is the prevention, identification and removal of duplicates, and incorporating rules to eliminate incorrect data from entering the system. The Child Welfare practice, by nature, requires interaction with a large number of electronic systems (e.g., SAWS, probation, courts) each of which utilize different identifiers to distinctly identify individuals. The master index approach seeks to help track, and therefore link, identifying information for entities across multiple silos of data. Two MDM-based approaches support searches and reduce the introduction of duplicates:

• Deterministic matching (e.g., last name, social security number); and
• Probabilistic matching (e.g., best case matching across multiple identifiers).

CWS-NS requires a probabilistic or hybrid approach to support search, de-duplication activities, and a rich set of definitive identifying data (e.g., mother’s maiden name, secondary client index number) that support identity verification and maintain the history of identifying information.

A good example of a system that utilizes MDM and probabilistic matching is the file clearance process used to obtain or verify a Client Index Number (CIN) from the Statewide Client Index (SCI). The SCI, Medi-Cal Eligibility Data System (MEDS), and its associated demographic data modification alerts comprise one of the more visible examples of a Master Person Index that utilizes MDM for individuals whose Health and Human Services program application events and eligibility are maintained in MEDS. While it cannot be considered a statewide identifier, the CIN has been useful in distinct identification because of the large number state programs that utilize MEDS to reduce the likelihood of dual enrollments. CWS-NS intends to obtain the latest probabilistic matching algorithms that HCS utilized in the Automated File Clearance web service for Contractor consideration. CWS manages a relatively small population of clients known to interface partners (e.g., SAWS, Probation) so CWS-NS will not be considered a definitive source for integrated regional MDM coordination. CWS-NS will collect, store, and maintain unique identifiers (e.g., CIN’s, County ID’s); share MDM data (e.g., revised address of a Service Provider) with partners; and build a foundation that can support formal MDM coordination in the future.

CWS-NS MDM seeks to achieve the following goals:

• Minimize the creation of duplicate entities (e.g., persons, service providers and facilities) through the use of comprehensive probabilistic matching techniques
• Support sparse data entry for entities that the business has little information on (e.g., referrals from community members)
• Prefill entity master data in forms and reports
• Utilize MDM and master indexes to correlate entities across partner data silos
• Provide capability to correct identifiers (e.g., SSN, CIN)
• Provide capability to merge true duplicates
• Provide capability to link and unlink related entities (e.g., family relationships)
• Maintain detailed history of index updates and merges

Source: RFP 7.0

CWDS Data and Development Principles

Principles play a key role in the underlying success of any project. They differ from traditional principles as they speak to the resulting experience of a person interacting with a digital solution.

Principles

California’s Agile Approach

Consistent with the approach utilized by 18F CWDS development adheres to the following principles:

• Use Free and Open Source Software (FOSS) - Software that does not charge users a purchase or licensing fee for modifying or redistributing the source code. This supports ACYF Interoperability goals to share development paid for with federal dollars with other States and for the project to contribute back to the open source community.
• Develop our work in the open.
• Publish publicly all source code created or modified by CWDS, whether developed in-house by state staff or through contracts negotiated by CWDS.

CWDS Data Principles

Principles - defined as a fundamental, primary, or general law or truth from which others are derived - are drafted to help to convey the anticipated approach and to elicit conversation. These principles are draft and may not have yet been immortalized as CWS-NS Project Decisions.

• Provide appropriate user access to all CWS-NS data sets unless there is a compelling reason not to;
• CWS-NS will utilize integrated and shared data structures across all program areas (i.e., CWS and Children’s Residential licensing) included within CWS-NS (i.e., avoid siloed code paths);
• CWS-NS will utilize shared components and code for common business functions across all program areas (i.e., CWS and Children’s Residential licensing) included within CWS-NS (i.e., avoid siloed code and digital services);
• Utilize distinct person identifiers to prevent duplicates;
• Leverage state Master Data Management systems to achieve system interoperability
• CWDS continue to “bring along” data exchange partners to utilize national data exchange format standards (e.g., ANSI, HL7, NIEM IEPD)
• CWDS will maintain full-time CWS-NS Data Quality team

API Data-Related Principles

These principles are draft and may not have yet been immortalized as CWS-NS Project Decisions.

• New functionality and new data goes into a “new database”.
• All data that is in the system / has ever been in the system must always be available online (“never throw anything away”).
• The new system/solution must be able to access all legacy data.
• Don’t break any existing batch extracts.
• New data will never be viewable within the legacy system.
• We want a database agnostic system.
• Documents required for services live in a document repository.

Reporting and Data Extracts

Click here for information about reporting needs and data extracts provided by the legacy system.

All content is Alpha