Southern California Central Coastal Regional –
SCCCR Collaborative
HMIS Requirements Document
d
e
s
r
o
d
n
E
October 2004
r
o
U.S. Department of Housing and Urban Development
Office of Community Planning and Development
d
e
v
Funding for this project was provided by the U.S. Department of Housing and Urban
Development.
o
r
p
N
t
o
p
A
y
b
H
U
D
SCCCR Collaborative – Requirements Document
Acknowledgements
This document was prepared on behalf of the Southern California Central Coastal Regional
(SCCCR) Collaborative through a subcontract with Aspen Systems Corporation, Rockville, MD
20850. Aspen’s contract (C-OPC-21191) is with the U.S. Department of Urban Development
(HUD), Office of Community Planning and Development (CPD). The author of this document is
Matt White. Michael Roanhouse, Government Technical Monitor, provided contract and project
oversight. Jim Smith, Aspen’s Project Director, provided project direction and guidance.
y
b
Many others contributed to this guide by providing information on their community’s
experience with HMIS. Special consideration is given to the entire Ventura County and
City Oxnard HMIS Steering Committee for that group’s strategic vision and guidance
throughout the HMIS planning process. In addition representatives from the Counties of
Santa Barbara and San Luis Obispo provided insight and direction.
d
e
s
r
o
d
n
E
Ventura County and City of Oxnard HMIS Steering Committee members:
Cathy Brudnicki, Ventura County Coalition for Housing and Homelessness
Susan Englund, Ventura County United Way
Carlos Jimenez, City of Oxnard
Rick Pearson, Project Understanding
Chris Reeve, Catholic Charities
Karol Schulkin, Ventura County
Mark Summa, Ventura County
Sandra Thompson, City of Simi Valley
Suzanne Zimmerman, Ventura County
r
o
Santa Barbara
John Mirk, Help of Ojai
Mike Sederholm, Santa Barbara County
d
e
v
San Luis Obispo
John Busselle, San Luis Obispo
o
r
p
N
t
o
p
A
H
U
D
SCCCR Collaborative – Requirements Document
Table of Contents
Overview .................................................................................................................1
Introduction..................................................................................................1
Guiding Principles .......................................................................................2
Part 1: System Design Elements ...........................................................................4
SCCCR Collaborative Structure ..................................................................4
Architecture..................................................................................................8
Hosting.........................................................................................................9
Functionality & Operational Levels.............................................................9
Data Standards & Taxonomy of Terms .......................................................9
d
e
s
r
o
d
n
E
y
b
Part 2: Data Management ...................................................................................11
Reporting....................................................................................................11
Data Quality ...............................................................................................13
Data Sharing...............................................................................................15
Part 3: System Security & Client Privacy Policies ...........................................20
Overview....................................................................................................20
Planning for HMIS Security ......................................................................20
Systems Security Mechanisms...................................................................21
Client Privacy Policies...............................................................................23
r
o
Part 4: Systems Integration Policies...................................................................24
Systems Integration Overview...................................................................24
Decision and Communication Strategy for Integration .............................27
d
e
v
Part 5: Where to Go from Here..........................................................................28
Software Selection .....................................................................................28
Implementation ..........................................................................................28
Technology Capacity .................................................................................29
Ongoing Planning ......................................................................................30
o
r
p
p
A
Appendix A: Description of TA Deliverables...................................................32
Appendix B: Data Management Issues .............................................................35
t
o
Appendix C: Data Security Concerns ...............................................................38
N
Appendix D: Implementation Concerns ...........................................................40
H
U
D
SCCCR Collaborative – Requirements Document
Overview
Introduction
This report sets forth the design recommendations for implementation of a Homeless
Management Information System (HMIS) in the Southern California Central Coastal
region including Ventura County, Santa Barbara County, and San Luis Obispo County.
H
An HMIS is a computerized data collection application designed to capture client-level
information over time on the characteristics and service needs of homeless persons.1 This
report presents background information on the development of technical specifications
and functionality requirements for the community’s HMIS plan. Recommendations for
continuing development and system enhancements are included within each report
section.
d
e
s
r
o
d
n
E
y
b
Four Continuum of Care Systems in San Luis Obispo, Santa Barbara, and Ventura
Counties are considering a collaborative approach to planning and implementation of a
regional HMIS. At the request of the Cities of Oxnard; San Luis Obispo County; Santa
Barbara County; Ventura County; the U.S. Housing and Urban Development (HUD) Los
Angeles Field Office (Field Office); and with the formal request from HUD Headquarters
in Washington, DC, a community-planning process was undertaken to identify system
requirements and software specifications for a collaborative HMIS structure. Throughout
this report the collaborative HMIS planning process and the membership of committees
and representatives participating in the planning process are collectively referred to as the
SCCCR Collaborative.
r
o
HUD, through a contract with Aspen Systems Corporation, hired an HMIS consultant to
develop a set of recommendations that would serve as a guide for the community in
selection of HMIS software and further development of HMIS system requirements.
d
e
v
Part 1 of the report, System Design Elements, provides an overview of the HMIS design
elements recommended for the SCCCR Collaborative and gives considerable attention to
the structure of the SCCCR Collaborative partnership.
o
r
p
Part 2 of the report, Data Management, presents issues related to the collection, sharing,
storage, and reporting of HMIS data. This section recommends standards for data
reporting, data quality, and data sharing. Policy and procedural protocols are
recommended to structure the management of information that supports data sharing
while maintaining client confidentiality and system security.
N
t
o
p
A
Part 3 of the report, System Security & Client Privacy Policies, recommends the necessary
design options essential for the ongoing use and integrity of HMIS data. The section
identifies specific privacy, confidentiality, and security protocols for the SCCCR
Collaborative.
1
Homeless Management Information Systems (HMIS) Data and Technical Standards Final Notice, Federal
Register Vol. 69, No. 146, Friday, July 30, 2004.
October 2004
U
1
D
SCCCR Collaborative – Requirements Document
Part 4 of the report, Systems Integration Policies, defines systems integration issues and
recommends specific policies and standards. Systems integration refers to the need in
some communities to integrate data from multiple sources into a single administrative
database. Integration is discussed at various levels including system wide, within each
continuum, and from provider database to HMIS database. Standards are recommended
and next steps are identified.
Part 5 of the report, Where to Go from Here, presents next steps related to
implementation, ongoing planning and training, software selection, and increasing
technological capacity. This final section of the report organizes issues related to further
technical assistance and training needs for long term community success and project
sustainability.
d
e
s
r
o
d
n
E
y
b
H
Guiding Principles
Ventura County Coalition for Housing and Homelessness (VCCHH) HMIS Steering
Committee members and representatives from Santa Barbara and San Luis Obispo
County government identified several goals for their partnership with HMIS
implementation.
• Economies of scale for software pricing and service costs associated with a
collaborative-wide implementation;
• Single software system among all providers;
• Ability to conduct analysis and comparison of homeless data across CoC
jurisdictions; and
• Leveraged ongoing planning and service coordination.
d
e
v
r
o
Following the completion of several community meetings in each of the SCCCR
Collaborative jurisdictions, a more explicit vision statement was developed with goals
and objectives for HMIS collaborations.
Vision
p
A
Mission
t
o
The SCCCR Collaborative is dedicated to providing the best possible,
highest quality homeless management information system (HMIS) to
enhance the continuum of care for persons experiencing homeless.
o
r
p
The SCCCR Collaborative will use HMIS to advance the provision of
quality services for homeless persons, improve data collection, and
promote more responsive policies to end homelessness in San Luis
Obispo, Santa Barbara, and Ventura Counties.
N
October 2004
U
2
D
SCCCR Collaborative – Requirements Document
Part 1: System Design Elements
SCCCR Collaborative Structure
HMIS structure refers to the underlying organizational and technical foundation for the
HMIS system and how these two components interface from an operational perspective.
Every community organizes their HMIS structure a bit differently with varying
possibilities for assignment of roles and responsibilities, communication flow, technical
architecture, and underlying business practices that support the operation of the HMIS.
Recommendations for the SCCCR Collaborative HMIS structure take into account the
unique strengths and opportunities that each partner brings to the Collaborative and
attempt to leverage these strengths to create the best possible fit for all the technical
components, organization of the HMIS management function, and project management of
the HMIS initiative.
d
e
s
r
o
d
n
E
y
b
H
The SCCCR HMIS Collaborative joins four separate Continuum of Care (CoC) planning
jurisdictions in three counties. In San Luis Obispo and Santa Barbara Counties the CoC
geographical jurisdiction is equivalent to the corresponding county. Ventura County is
divided into two separate CoC jurisdictions, one representing the City of Oxnard and the
other representing the remainder of Ventura County exclusive of Oxnard. The partnership
between Oxnard, Ventura, Santa Barbara, and San Luis Obispo is advantageous for the
following reasons:
1. All parties serve a similar client population.
2. There are service providers with operations in two or more jurisdictions within the
Collaborative.
3. All parties have a vested interest in creating a uniform system for measuring the
utilization of homeless services throughout the region.
d
e
v
r
o
Although the SCCCR Collaborative has have been cooperatively working on HMIS
planning issues for the past year, no formal partnership agreement or collaborative
governance structure among the four organizations identifies the terms for this joint
HMIS venture. While leadership within each organization has expressed a committment
to the collaborative process and is actively engaged in solution-oriented HMIS planning,
each partner must agree to a formal collaboration agreement. The collaboration
agreement will outline the structure of the partnership, describe all the technical
components of the HMIS and how they fit together, describe the organization of HMIS
management functions, and recommend a project management strategy for the HMIS
initiative.
o
r
p
N
t
o
p
A
Structure Recommendations:
1. The SCCCR Collaborative will develop a partnership agreement that describes the
role and scope of each of the following technical components:
• Database Servers
• Application Servers
• User’s access to their system within the infrastructure
• Restrictions/limits of the structure
October 2004
U
3
D
SCCCR Collaborative – Requirements Document
2. The SCCCR Collaborative Partnership Agreement will allow for changes and
adjustments to the recommended partnership structure:
• Recognize that the structure will evolve over time
• Define clear phases for the evolving structure
• Adopt the organization and project management functions to the evolving
structure
3. The SCCCR Collaborative will develop an organizational structure for HMIS
governance and project management to include the following:
• An governing body or steering committee with leadership representation
from each of the Collaborative partners
• Collective collaborative resource coordination to manage programmatic
technical assistants, trainers, data analysts, report writers, and technical
support personnel
• Project managers from each participating CoC region
4. Standardize the implementation and operation of HMIS functionality components
by using a phased-in approach to their use. Major functionality components
include client intake and exit, client assessment, service planning and outcome
monitoring, case management, and information and referral. Following is the
recommended approach to phasing-in the various components of the system.
However, simultaneous implementation of some functionalities could be
warranted, a likely example could be the information and referral component.
• Functionality Phase 1
o Client intake and exit
o Client assessment
• Functionality Phase 2
o Service planning and outcomes
• Functionality Phase 3
o Case management
• Functionality Phase 4
o Information and Referral
5. Phase in more complicated and technically difficult HMIS structural alternatives
such as aggregating and sharing options after a basic foundational structure is
successfully established.
6. Lease independent and autonomous HMIS database space within each local CoC
planning jurisdiction.
• Each Continuum of Care (CoC) within the collaborative will lease its own
HMIS database where all local CoC client data will be stored. The
possible exception is Ventura and Oxnard which may elect to collectively
lease database space for the two CoC jurisdictions.
• All CoC jurisdictions will adopt the national HMIS technical and data
standards.
• All CoC jurisdictions will adopt a local data set that goes beyond the
minimal standards established by HUD.
• Each CoC will establish its own independent process to determine the
local data sets (if any) that identify specific data elements in addition to
the Annual Homeless Assessment Report (AHAR) requirements.
o
r
p
N
t
o
d
e
v
r
o
d
e
s
r
o
d
n
E
y
b
H
p
A
October 2004
U
4
D
SCCCR Collaborative – Requirements Document
7. Maintain independent and autonomous HMIS application servers within each
local CoC planning jurisdiction.
• Each CoC within the collaborative will maintain separate HMIS software
application servers.
• Each CoC within the collaborative will maintain significant independence
and flexibility for operating and managing their system.
• Each CoC within the collaborative will formalize a process for dealing
with application enhancements and upgrades.
8. Limit user access to the data contained within each CoC database system. User
access to the system’s data should be governed by the SCCCR Collaborative user
access policies and specific policies at the agency level.
y
b
H
Structural recommendations call for limitations and restrictions of data sharing during
Phase 1 of implementation. Day-to-day data sharing of client information among CoCs is
not possible given the distribution of separate database servers among each of the
collaborative jurisdictions. While unduplicated counts of clients served can be
determined at the CoC level, a single aggregate count at the collaborative level will not
be initially possible without integration of multiple databases. Figure 1.1, Phase 1 HMIS
Structure, demonstrates how multiple homeless service providers will maintain separate
CoC-specific HMIS database structures.
Figure 1.1
Phase 1 HMIS Structure
SCCCR Collaborative
Recommended Basic HMIS Structure
Lead agencies are
application and data
custodians.
Databases reside within
their community.
CoC 2
CoC 1
d
e
v
Data
Data
Database Server
r
o
d
e
s
r
o
d
n
E
Database Server
Web
Application
Server
CoC 1 User 1 at Agency 1
Firewall
p
p
ro
CoC 3
Data
Web
Application
Server
Database Server
Firewall
Internet
Fast connections required
for effective operation
…..
N
Coc 3 User 2 at Agency 5
Coc 3 User 2 at Agency 1
Coc 1 User 3 at Agency 20
Coc 2 User 1 at Agency 1
Coc 2 User 2 at Agency 7
Agency Computers
connect to the Internet and
access the HMIS with a
Browser
o
Firewall
…..
…..
Coc 1 User 2 at Agency 1
A
t
Web
Application
Server
Coc 3 User 1 at Agency 1
Coc 2 User 1 at Agency 8
Coc 2 User 1 at Agency 10
Coc 2 User 2 at Agency 12
The necessary level of database integration to obtain unduplicated regional counts is
recommended for Phase 2 of implementation. A regional database that includes
October 2004
U
5
D
SCCCR Collaborative – Requirements Document
aggregate data from all participating partners provides a pool of data for regional analysis
and reporting, and enables the computation of unduplicated counts at the collaborative
level. Figure 1.2, Aggregate Database Structure, provides a graphic representation of the
structure necessary for independently hosted HMIS databases, allowing the integration
necessary for aggregate SCCCR Collaborative data in Phase 2.
U
Figure 1.2
Aggregate Database Structure
LA /O C C ollaborative
R ecom m ended A ggregate H M IS S tructure
L ea d A g e ncie s a re
A p p lica tio n a n d D a ta
C u sto d ia n s.
D a ta b a se s re sid e w ith in
th e ir co m m u n ity
D a ta
D ata b a se S e rve r
C oC 2
CoC 1
D a ta
D a ta
D a ta b a se S e rver
W eb
A p p lica tio n
S e rver
d
e
s
r
o
d
n
E
C oC 3
D a ta
D a ta ba se S e rve r
F ire w a ll
W eb
A p p lica tion
S e rve r
… ..
D a ta b ase S e rve r
F ire w a ll
In te rn et
C o C 1 U se r 1 a t A g e n cy 1
Fa st co n n ectio n s re q u ire d
fo r e ffe ctive o p era tio n
W eb
A pp lica tio n
S e rve r
Fire w a ll
… ..
… ..
C oc 1 U se r 2 a t A g en cy 1
C o c 1 U ser 3 a t A g e n cy 2 0
C o c 2 U se r 1 a t A g e n cy 1
A g e n cy C o m p uters
co n n e ct to th e In te rn e t a nd
a ccess th e H M IS w ith a
B ro w se r
C o c 2 U se r 1 a t A g e n cy 1 0
o
r
p
H
y
b
A g g re g a te d d a ta ba se
m a in ta in e d b y a n a g e n cy
a p p o in te d b y L A /O C
co llab o ra tive
d
e
v
r
o
C o c 3 U se r 2 a t A g e n cy 5
C o c 3 U se r 2 a t A g e n cy 1
C o c 2 U ser 2 a t A g e n cy 7
C o c 3 U se r 1 a t A ge n cy 1
C o c 2 U se r 1 a t A ge n cy 8
C o c 2 U se r 2 a t A g e ncy 1 2
An aggregate database structure as shown in figure 2 requires adequate policies and
procedures to govern the appropriate administrative structure for the aggregate database.
Some key concerns that policies and procedures should cover include access to the
database, manipulation and analysis of aggregate data, release of data, and release of
analytical reports. The SCCCR Collaborative will also need to ensure high quality
aggregate data by developing operating guidelines for the collection, validation and
acceptance or rejection of new data into the database.
N
t
o
p
A
In addition to database structure recommendations, organizational and project
management roles need to be defined and filled within the collaborative structure. These
roles include a comprehensive oversight body or steering committee that provides
guidance on HMIS development and ensures consistency with original HMIS vision and
goals. Immediately following the governing body is a collaborative resource
coordination role that organizes the deployment of technical assistance, training, data
analysis, and technical support to organize the various CoC efforts, managing and
October 2004
6
D
SCCCR Collaborative – Requirements Document
supporting their independent HMIS systems. Although initial recommendations call for
separate database servers for each CoC jurisdiction with independent governing
structures in place for each CoC, a regional approach to information sharing and project
planning will ensure that resources are allocated in an effective and equitable manner
across continuums. Figure 1.3, SCCCR Collaborative Organizational Structure,
highlights a three tiered organizational structure with the SCCCR oversight body as the
top tier, HMIS collaboration and resource management are positioned as a middle tier,
and each independent CofC jurisdiction feeding into the regional organizational structure.
Figure 1.3
SCCCR Collaborative Organizational Structure
d
e
s
r
o
d
n
E
y
b
H
SCCCR Oversight Body
HMIS Collaborative Management Coordination
LAHSA
HMIS Collaborative
Resource Management
Glendale
d
e
v
r
o
Orange County
Pasadena
Long Beach
Architecture
HMIS architecture describes the configuration of technical HMIS solution components
including user interface, application, database, and the underlying programming language
in which the software application is written. Architecture is the foundation on which an
HMIS is designed and, for that reason, is often one of the initial considerations that a
community evaluates in the development of a community-wide HMIS solution.
o
r
p
Recommendation:
The SCCCR Collaborative HMIS should operate as a web-enabled system with access to
the database via an Internet browser over a TCP/IP connection. Users of the HMIS
access the application by using a web browser such as Netscape or Internet Explorer. The
HMIS software solution must be compatible with a centralized system, meaning that the
software application and client data are capable of being housed on a single community
database. All users will connect to this centralized database to add, edit, or view data in
real-time.
N
t
o
p
A
Hosting
October 2004
U
7
D
SCCCR Collaborative – Requirements Document
Hosting refers to the entity that administers the central database and the application
server. Hosting often involves a high level of technical capacity for database
administration, maintenance, trouble shooting, management of accounts, data storage,
and back-ups, and security.
Recommendation:
The HMIS solution provider will host and administer the central database and application
server for each of the CoC partners within the SCCCR Collaborative. This allows for the
SCCCR Collaborative to take advantage of the expertise and experience of the software
vendor. The technical expertise and hosting capacity within the Collaborative is not
consistently available from each partner and the expense of in-house system
administration staffing may be cost prohibitive.
d
e
s
r
o
d
n
E
y
b
H
Functionality & Operational Levels
The functionality and operational levels of the HMIS are identified as business
requirements and system requirements that enable providers to collect and manage the
types of client information that are most pertinent to the provision of housing and
services for clients experiencing a housing crisis. Multiple functionality levels were
identified by the community during community meetings and presentations. An HMIS
configuration could include any number of these functionality levels, but must contain
client intake and exit at a minimum. The major functionality levels include:
• Client intake and exit
• Client assessment
• Service planning and outcomes
• Case management
• Information & Referral
d
e
v
r
o
Recommendation:
Software selection will be predicated on the ability of the software system to perform all
functionality levels identified in this report. During the initial stages of HMIS
implementation client intake and exit, client assessment, and information and referral will
be the primary functionality levels supported by the SCCCR Collaborative. In later
stages of HMIS development and implementation beyond Phase 1, the SCCCR
Collaborative will support the development and use and expanded HMIS functionality to
include service planning and case management.
o
r
p
N
t
o
p
A
Data Standards & Taxonomy of Terms
Uniform data standards (data elements, definitions, and data collection methodologies)
are needed so that communities can generate HMIS reports with uniform meaning and
completeness. The consistency of HMIS reports will make it possible to compare the
characteristics of homeless populations and the services provided both within and across
CoCs in the collaborative. HUD has released a report on the Data and Technical
Standards for HMIS to provide guidance and consistency in the way that communities
develop their HMIS initiatives.
October 2004
U
8
D
SCCCR Collaborative – Requirements Document
Recommendation:
The SCCCR Collaborative will incorporate the data standards from the HUD Data and
Technical Standards Report pending that report’s final release. Beyond the scope of the
HUD Data and Technical Standards Report, the SCCCR Collaborative will follow the
AIRS Taxonomy for naming and definitions of specific services and client
characteristics.
o
r
p
t
o
d
e
v
r
o
d
e
s
r
o
d
n
E
y
b
U
H
p
A
N
October 2004
9
D
SCCCR Collaborative – Requirements Document
Part 2: Data Management
This section is divided into three sections; Reporting, Data Quality, and Data Sharing.
Reporting
The reporting function of data management refers to the extraction of both aggregate data
and client-level data, the format for reported data, and the management of the reporting
process. All HMIS software providers are able to program specific reporting functions
and then standardize those reports so that HMIS users are able to run standard reports for
different time periods while maintaining consistent formats. Additionally, every
homeless assistance funder requires homeless service providers to submit reports that
detail unduplicated counts of clients served and the characteristics and profile of client
populations. Increasingly, HMIS participants are using the reporting function of the
HMIS product to conduct community wide analysis of services provided, client
outcomes, trend analysis, and to assist with CoC gaps analysis computations. For all of
these reasons HMIS system planners need to approach the HMIS reporting function in a
plannful and intentional manner to assure that the desired report formats and the basic
building blocks of those reports (data elements) are identified early on in the planning
process.
d
e
s
r
o
d
n
E
H
y
b
The SCCCR Collaborative considered the reporting function as an important component
of the technical assistance process culminating in the development of the Requirements
Document. Community members involved in the process identified that the SCCCR
Collaborative will need to create appropriate methods or vehicles for system wide data
release of aggregate information, which may include web sites, reports, public
presentations, and grant applications. In addition to standard reports such as the HUD
APR, CAPER, and client served reports, the community must also define additional
reporting needs and policies and protocols for report dissemination. Although each
participating provider must have the ability to create customizable report formats to meet
the needs of internal agency research, analysis, and funder reporting, some of these report
generation functions can be standardized.
o
r
p
d
e
v
r
o
Data Management – Reporting Recommendations:
p
A
Data Retrieval Process
SCCCR HMIS users will only retrieve client data relevant to the delivery of services to
people experiencing a housing crisis.
The database should not be used to retrieve or report information not related to
serving people in housing crises or planning for the elimination of homelessness.
N
t
o
Data Retrieval Access
Connecting agencies will have access to retrieve any individual and aggregate data
entered by their own programs. Connecting agencies will not have access to retrieve
individual records entered by other programs except when data is explicitly shared
through an HMIS Sharing Agreement, and with the explicit consent of the client.
October 2004
U
10
D
SCCCR Collaborative – Requirements Document
Connecting agencies will not have access to retrieve aggregate data for other agencies or
system-wide.
Users should determine the level of access to data at the time of data entry. That
level of access can be changed as confidentiality requirements and HMIS Agency
Agreements change. An HMIS report-writer function should limit user access and
only report data from records to which the individual user has access.
Data Access by Software Provider
The HMIS software provider will not have access to individual or aggregate data
contained within the HMIS without the explicit permission of the community for
purposes of software maintenance and/or data conversion.
The community will require the HMIS software provider to sign an agreement
that no staff member will access the HMIS without the explicit permission of the
community.
d
e
s
r
o
d
n
E
y
b
H
Data Access by Client
Any client will have access on demand to view, or keep a printed copy of, his or her own
records contained in the HMIS. The client will also have access to a logged audit trail of
changes to those records. No client shall have access to another client’s records in the
HMIS.
It is important to note that the information provided to the client will only include
the client information to which the agency has access. If there are other service
records entered by other agencies to which the providing agency does not have
access, those records will not be provided.
r
o
Data Access by SCCCR Collaborative Oversight Body
The SCCCR HMIS Oversight Body, through the Systems Administrator will have access
to retrieve all data in the HMIS. The System Administrator will not access individual
client data for purposes other than maintenance and checking for data integrity. The
SCCCR HMIS Oversight Body will only report client data in aggregate form.
The SCCCR HMIS Oversight Body will oversee all aggregate reporting for the
Community.
o
r
p
Data Ownership
The SCCCR HMIS, and any and all data stored in the SCCCR HMIS, is the property of
the SCCCR Oversight Body. The SCCCR Oversight Body has final control over the
creation, maintenance and security of the HMIS.
In order to ensure the integrity and security of sensitive client confidential
information and other data maintained in the database, the SCCCR Oversight
Body will require all connecting agencies to sign the HMIS Agency Agreement
prior to being given access to the HMIS. The HMIS Agency Agreement includes
terms regarding the maintenance of the confidentiality of client information,
provisions regarding the duration of access, an acknowledgement of receipt of the
Policies and Procedures Manual, and an agreement to abide by policies and
procedures related to the HMIS including all security provisions contained
therein.
t
o
N
d
e
v
p
A
October 2004
U
11
D
SCCCR Collaborative – Requirements Document
Data Retrieval Support
Connecting agencies will create and run their own agency-level reports.
The SCCCR Oversight Body will provide the template for standard reports and
funder required reports. Connecting agencies will then execute standard reports
and any customized reports from their agency.
Extracted Data
HMIS Users will maintain the security of any client data extracted from the database and
stored locally, including all data used in custom reporting. HMIS users will not
electronically transmit any unencrypted client data across a public network.
The custom report-writer function of most software products allows client data to
be downloaded to an encrypted file on the local computer. Once that file is
unencrypted by the user, confidential client is left vulnerable on the local
computer, unless additional measures are taken. Such measures might include
restricting access to the file by adding a password.
d
e
s
r
o
d
n
E
y
b
H
Data Retrieval by the Public
The SCCCR HMIS Oversight Body will address all requests for data from entities other
than Connecting Agencies or clients. No individual client data will be provided to any
group or individual that is neither the connecting agency which entered the data nor the
client him or herself without proper authorization or consent.
Any requests for reports or information from an individual or group who has not
been explicitly granted access to the HMIS will be directed to the SCCCR HMIS
Oversight Body. No individual client data will be provided to meet these requests
without proper authorization or consent.
d
e
v
r
o
Data Quality
Data quality problems can become a major barrier to the usability of the available data in
an HMIS. Each HMIS jurisdiction will need to determine the extent of potential data
quality problems and their ability to mitigate them, in order to determine if the data is fit
for use. The success of HMIS depends on the ability to integrate a large number of highly
disparate sources of data collected under a variety of different circumstances. Each
provider, for example, has its own approach to managing the data collection process;
therefore each has a different set of minimal standards of acceptability. Identifying and
determining the specific data quality issues that needed to be addressed in order for the
data to be included in an HMIS is a major part of the development process for each
community.
o
r
p
N
t
o
p
A
HMIS data quality standards identify the policies, processes and materials that homeless
assistance organizations and local programs should have in place. These standards will
assure the collection of valid and reliable data for their HMIS and for participation in
cross-jurisdictional research, evaluation, and analysis.
October 2004
U
12
D
SCCCR Collaborative – Requirements Document
Data Foundation and Structure Recommendations:
An HMIS must have the foundation and structures in place for collecting quality data that
meet HUD’s guidelines. Each community will implement specific data quality protocols
that address HUD standards and reflect the unique needs and goals of the community’s
HMIS. Potential standards might measure whether the HMIS has policies for data
collection and quality reviews; whether local programs know these policies and whether
the HMIS administrator conducts validity studies to ensure processes are working to
produce accurate and reliable data. Some potential examples…
H
HMIS has written policies that specify:
Standardized data collection tools appropriate for persons experiencing a housing
crisis.
Time periods (in days) for when to collect intake/entry, exit/outcome, and
experiential/transactional data.
Appropriate guidance on data collection for special populations who are unable to
participate in data collection due to language or disability (SMD or inebriation).
Definitions for all common community data elements, defined according to HUD
Data Standards, provided in writing to all programs.
A comprehensive data dictionary, which defines all data elements on data
collection forms and in the HMIS data system, provided with an explanation and
appropriate training to all participating HMIS programs.
Provision of technical assistance, training, and additional resources for effective
assessment, data collection and follow-up procedures.
HMIS has a system for verifying that participating programs are following HMIS
data policies and procedures through program reviews, auditing or a certification
process.
HMIS has conducted (or reviewed reports of) the validity, reliability and
comparability of standard data collection tools and other data collection
instruments (interviews, focus groups, surveys).
Potential Standards Grouped by Category:
Data Collection and Verification
The CoC jurisdiction has an electronic homeless management information system
(HMIS), used by all programs, that has individual client records within a
relational data base structure. The HMIS incorporates HUD Data Quality
Standard measures using common definitions and categories.
The HMIS has error checking functions used by participating programs (e.g., that
identify out-of-range values and missing data).
The HMIS Administrator has standardized forms (electronic or paper) for
collecting consumer information (e.g., intake, attendance, goal setting) that
include all HUD Data Standard measures and have correct definitions and
categories.
All participating programs have staff with clear responsibility for data collection
and data entry.
o
r
p
t
o
N
d
e
v
r
o
d
e
s
r
o
d
n
E
y
b
p
A
October 2004
U
13
D
SCCCR Collaborative – Requirements Document
HMIS administrative staff checks data for errors after submission by participating
programs.
Participating programs conduct at least daily data entry into HMIS. All clientlevel data is entered into the HMS within 24 hours of collection from client.
HMIS staff reviews data at least quarterly for errors, missing data, out-of-range
values and anomalous data, and to identify program improvements.
HMIS staff has timely (e.g., quarterly) follow-up back to participating programs
to have them correct missing and erroneous data.
HMIS staff has a regular system for verifying (through software, onsite auditing,
contact with local staff) that participating programs are following HMIS data
collection procedures.
y
b
H
Data Analysis and Reporting
The HMIS can produce required reports for funders, including the HUD APR.
The APR is calculated accurately to include error checks and prevent double
counting. HMIS staff (or designee) checks HMIS reports for errors and missing
data and obtains corrected data from local program reports when necessary.
HMIS staff person familiar with the data, but not directly involved with collection
and data entry, reviews data reports for errors and accuracy.
Program staff uses data for program management and improvement.
Programs can access data reports that are useful for program management and
improvement.
HMIS staff has a system of regular contact with providers to review data analysis
issues and reporting needs and to identify technical assistance needs.
HMIS staff has documented procedures for dealing with analysis problems and
deviations.
HMIS staff compares data among programs and with prior years’ data for
discrepancies, reasonableness and to identify trends in performance.
HMIS staff has procedures to verify that provider reports accurately reflect data
collected (e.g., through review of local program documentation, onsite auditing).
Staff Development
Homeless assistance providers and HMIS staff have received training on general
data collection requirements, including assessment policy and procedures, followup policies and goal setting procedures.
Homeless program staff has received training on data collection procedures.
Program provider staff has been trained on data entry into the local HMIS.
Program provider staff has had training on how to produce and/or interpret reports
produced by the HMIS.
Training has been provided on conducting follow-up survey or data matching
procedures, to program provider staff involved in survey or matching.
o
r
p
N
t
o
d
e
v
r
o
d
e
s
r
o
d
n
E
p
A
Data Sharing
HUD has determined that while local providers will be required to report a limited
amount of client level data to the CoC’s central data storage facility on a regular basis,
October 2004
U
14
D
SCCCR Collaborative – Requirements Document
sharing of HMIS data among providers within the CoC is not required by HUD and is at
the discretion of each CoC. However, to assist in client case planning and provide the
most effective service delivery throughout the SCCCR system, some providers may
choose to share client-level data among separate programs. This sub-section of the
Requirements Document identifies current sharing practices, recommends development
of additional sharing guidelines, and identifies the specific requirements for a consumer
consent process.
d
e
s
r
o
d
n
E
y
b
The SCCCR Oversight Body will need to develop policies and procedures that govern
who (or what entity) has access to data and to which types of data. The HMIS System
Administrator and appropriate HMIS management staff require access to the complete
HMIS database for purposes of maintenance, management, and monitoring. Beyond
required systems maintenance and management; client-level data can only be shared
among providers with a signed Sharing Agreement and authorization from the client in
the form of a signed Release of Information.
Decisions regarding data sharing must be grounded in the existing practices of the
community. Two core questions were considered during this planning process in an
effort to develop sharing recommendations for the SCCCR Collaborative.
r
o
1. What are the common data sharing practices of the communities/continuums?
Existing practice with regard to data sharing within the larger SCCCR Collaboration
is mixed. The majority of respondents at various workshops and conferences
indicated that sharing is accomplished through the traditional “informed consent”
process. Sharing is individualized, time-limited and based on the unique needs of the
consumer. However, one locality of co-located providers offered a seamless interface
between services. These providers use a single records room, and are sharing files.
o
r
p
2. What was the participant perspective on sharing?
Participant’s perception of data sharing was based on the type of service as well as
current sharing practice of their organization. Those organizations that manage
higher risk data clearly had significant concerns about sharing information. Trust
between providers regarding the “chain of custody” would obviously impact the
success of any sharing practice. The location that is currently routinely sharing
records had obviously developed a high degree of trust in the security and privacy
practices of the partnering organizations and their shared records management
process. Beyond concerns about how shared information would be used and
protected, two issues were identified that would limit the utility and wisdom of
universal data sharing. These concerns include:
t
o
N
d
e
v
p
A
October 2004
U
H
The community must determine what standard level of data sharing is appropriate for
effective service planning and delivery. That minimum will become the standard from
which variances from that procedure can be negotiated among providers. Beyond the set
of standard data elements for data sharing, each provider can negotiate additional sharing
or more restrictive sharing on a case-by-case basis. Providers will make these
determinations based on program management and individual case planning needs.
15
D
SCCCR Collaborative – Requirements Document
Access and availability of computers to allow staff to access the shared
record at the time of interview – maximizing the paper work reduction
benefits of data sharing.
Security and privacy of the physical space where computers are located –
insuring confidentiality and adequate protection against unauthorized
access to machines. This issue was most clearly expressed by the colocated provider group that is already sharing client records and is a
serious concern for many other providers.
H
However, participants were also receptive to the benefits that could accrue to
consumers and organizations when data sharing occurs. Some were even uncertain
about what the benefits of the HMIS would be without data sharing. They were also
interested in the newer technologies that offer the opportunity for customized sharing.
d
e
s
r
o
d
n
E
y
b
Existing policies reflect the current data sharing practices of the providers. No CoC-wide
policies were identified during the workshops. The co-located providers who currently
share a file system had developed interagency agreements and client level consents.
Many of the organizations had not adopted / revised their existing consents to meet
HIPAA standards and were in general unsure how HIPAA applied to them. Policy
development was identified as a significant need.
Collaboration Level Recommendations:
1. Select software that supports data sharing and fully enable that functionality at the
CoC level. However, database design and processes to achieve an unduplicated
count should allow for multiple records from the same consumer. This also allows
consumers to elect not to “data share” while still agreeing to participate in the
HMIS process. Additionally, with regard to software design, insure that
programming accommodates time-limited information. For example, Homeless
Certifications and many Consumer Consents have a limited life span.
2. Make actual implementation of data sharing protocols a second phase in the
overall implementation strategy. Pilot the process with a willing group of
providers who are committed to the possible benefits of data sharing. Although
the overall philosophy of the SCCCR Collaborative may be to support data
sharing between providers, providers will carry most of the liability around
sharing. It will take time for organizations to feel safe with the new system and to
complete the necessary training/re-training regarding privacy practices in an
automated environment without introducing data sharing.
3. Data Sharing offers some significant potential benefits to consumers. Therefore,
the SCCCR Collaborative should adopt a philosophy and define recommended
data sets and protocols for sharing prior to the pilot – define a best practice for
providers. The SCCCR Collaboration should revisit its philosophy and
recommendations with input from the pilot group. Of special interest are those
fields that support certification of homeless status and non-disability information
used to qualify for entitlements. Identifying information must be shared to
accomplish data sharing. However disability data, current address and specific
o
r
p
N
t
o
d
e
v
r
o
p
A
October 2004
U
16
D
SCCCR Collaborative – Requirements Document
organization (e.g. domestic violence) could be omitted. The planning process
around data sharing issues will need to be very transparent.
4. Explore HIPAA compliance issues as they relate to specific client confidentiality
requirements in California. Once data sharing stipulations are identified, sample
agreements/consents should be approved. Policies defining training requirements
and use of the various forms will need to be developed. In addition, consumer
involvement in the development of consents is very helpful.
o
r
p
N
t
o
d
e
v
r
o
d
e
s
r
o
d
n
E
y
b
p
A
October 2004
U
H
Provider Level Recommendations:
1. Evaluate audit trails required from the system. Develop a policy regarding what
paper records are needed. Develop methods for identification of records/persons
that are missing or incomplete in the system. The most common data quality
issues are simply missing or incomplete records. Data Sharing can impact the
willingness of staff and clients to participate in complete data collection. Develop
data integrity standards, including a verification cross-reference process for the
number served. Passive withdrawal from the HMIS system by providers
unwilling to participate is the worst outcome as it can lead to assumptions about
the number of homeless that are invalid. Community leadership and sometimes
provider leadership have no way of knowing if line staff is simply bypassing the
system. Only individual organizations can monitor actual participation.
2. Decisions regarding what to share with whom will fundamentally be made at the
provider level. To identify opportunities where data sharing would benefit the
consumer, a group exercise including leadership and direct service staff will be
helpful. This mapping process will also allow leadership to make the case for
data sharing and to get a clear idea regarding the actual practice/culture within
their organization. Informal sharing practices should be explored in a nonthreatening environment. If direct service staff does not support data sharing,
leadership should re-evaluate participation as staff will largely determine the level
of consumer willingness to participate in the overall HMIS system. The process
for mapping data sharing practices is outlined below.
a. Map upstream and downstream organizations – make a list of those
organizations that most consumers are referred to or are referred from, as
well as those that most clients also participate in, whether or not formal
referrals are made.
b. Identify fields (intake or assessment questions) staff believes generate
good information and feel relatively safe including in an automated
sharing protocol (routine sharing). To determine which field to share, the
following questions may be helpful.
3. Generally speaking, consents and agreement should include:
a. Informed Consumer Consent to Release Information – HIPAA compliant
allowing release of specific information to specific organizations/persons
for a specific time period. In a data-sharing environment these are needed
for sharing not covered under the Consumer/System Agreements. This is
the core release if practice is “no sharing.”
17
D
SCCCR Collaborative – Requirements Document
b. Consumer / System Agreements – provides a description of the HMIS
process, its benefits and the privacy safeguards. This form also defines the
client’s rights with regard to their information.
c. Agency / System Agreements – defines the relationship and
responsibilities of the Agency and the HMIS system.
d. Agency / Agency Agreements – defines the data sharing relationship
including the privacy and security requirements of both parties.
Organizations define exactly which fields they intend to share.
H
Client Consent Recommendations:
Insure that all systems have a process for the consumer to consent to the sharing of data.
A Consumer Consent is required no matter what the level of data sharing has been
negotiated. Test the language and consent and presentation processes and procedures to
insure that consumers understand the releases they are signing. This is a good place to
involve homeless consumers in the planning process. Plan for what happens if the client
does not give permission to share or elects not to participate in the HMIS. Remember
that HUD has said that you cannot deny services based on failure to participate in HMIS.
Client consent should be a two step process:
1. Systems Level Consent: Consent to participate in the organization’s HMIS
system. If data sharing is adopted, this consent defines sharing practices and
security/privacy protocols. This consent will generally include what the system is
and the benefits of participation:
a. To validate services (audit function by funding organizations),
b. To generate routine reports necessary to support funding.
c. To track community wide utilization and outcomes,
d. To identify unmet needs,
e. To learn about homelessness,
f. To support funding requests and allocation of resources.
g. To improve the program’s services.
h. A description of privacy/security protocols and procedures.
i. If the organization is also a funding source, then the right to audit clientlevel data for purposes of validating services is inherent. If the
organization managing the database is not a funding organization, then the
release will need to include language that specifies conditions under which
database administers have a right to look at record level data.
2. Informed Consent: Consent for non-routine sharing with specific organizations
for purposes of delivering services.
o
r
p
t
o
d
e
v
r
o
d
e
s
r
o
d
n
E
y
b
p
A
N
October 2004
U
18
D
SCCCR Collaborative – Requirements Document
Part 3: System Security & Client Privacy Policies
Overview
Designing and maintain a secure system is essential to the ongoing use and integrity of
the HMIS. Potential users of the system will not support data collection and sharing
unless security is diligently addressed throughout the HMIS development and
implementation process. Agency staff, consumers, policy analysts, funders, researchers,
and anyone else who might use HMIS data for appropriate purposes will necessarily be
invested in the security of the systems and mechanisms put in place to enforce and
monitor system security. This section highlights some privacy protection standards that
have been developed by other communities and recommends policies and procedures to
secure the confidential information of vulnerable clients in the SCCCR Collaborative
region.
d
e
s
r
o
d
n
E
y
b
H
Privacy in the context of HMIS refers to the protection of the rights of clients and clients’
data. Specifically, privacy is the protection of the personal client information stored in
the HMIS from open view, sharing, or inappropriate use through means of technology
(security) or policies (confidentiality). The SCCCR Collaborative HMIS will operate in
accordance with California State and federal laws and regulations related to
confidentiality, including but not limited to medical, mental health and substance abuse,
and domestic violence information about individual clients. These types of security
measures primarily protect client records from being accessed, changed, or shared by
unauthorized users.
r
o
Technological advances in HMIS software in the past several years are providing
increasing levels of security, constraints, and control of private and confidential client
information. The technical solutions to privacy which might include firewalls,
encryption, added servers, and authentication measures will be presented in this section
of the Requirements Document.
d
e
v
In addition to the technological means for securing HMIS systems, the SCCCR
Collaborative must also develop confidentiality policies and procedures to control the
human behavior side of HMIS development and use. Recommendations for
confidentiality policies and procedures will be provided in this section.
o
r
p
N
p
A
Planning for HMIS Security
Prior to the involvement of HMIS technical assistance efforts, the HMIS Planning
Steering Committee agreed on several key HMIS decisions that impacted ongoing
recommendations for HMIS development. These key HMIS decisions were the
following:
• The HMIS system will be web-enabled with access to the database(s) via an
Internet browser or TCP/IP connection;
• The HMIS solution provider will host and administer the central database(s) and
application server(s);
t
o
October 2004
U
19
D
SCCCR Collaborative – Requirements Document
•
•
•
Agencies with existing systems must have the ability to integrate with the HMIS
for the purpose of generating an unduplicated count of persons served;
The HMIS will operate in accordance with California State and federal laws that
affect the sharing of client identified data; and
The SCCCR HMIS Collaborative will develop policies and procedures to ensure
privacy and confidentiality of clients at the system level including informed and
written consent procedures as well as interagency data sharing agreements.
Given these key areas of HMIS development and decision-making as starting points, the
HMIS technical assistance consultants focused their security planning in three primary
topic areas and to offer participants the ability to identify the issues and/or concerns that
they had and recommend solutions based upon other HMIS or MIS models. The three
questions included:
1. What technical security measures are necessary to ensure privacy?
2. What policy level security measures are necessary to ensure privacy?
3. Who has access to client-level data, and under what circumstances?
d
e
s
r
o
d
n
E
y
b
H
Throughout the community planning process, security planning discussions were
presented within the context of existing data sharing practices between agencies.
Recommendations for the future HMIS framework were built upon these existing data
sharing practices. What emerged from this process is an image of an HMIS that will
need to be implemented with flexibility around data sharing capabilities, however the
technical infrastructure will include as many security mechanisms as possible and
policies and procedures need to be developed to account for human actions. Feedback
from participants in community meetings consistently identified the strong need for
training of all users of the system not only on the system itself but on the policies and
procedures and privacy protection issues.
d
e
v
r
o
Systems Security Mechanisms
The following web-based security model presents a recommended technical structure for
the SCCCR Collaborative HMIS. This web-based model is applicable at the agency,
continuum of care, and community-wide levels, with a duplication of the model within
each level of the HMIS structure. Figure 3.1 provides a graphic representation of the
recommended web-based security model.
o
r
p
p
A
The first level of this system is the individual user’s computer – the equipment that the
end-user uses to access the HMIS. Most often referred to as a desktop, personal
computer, or workstation. It is normally connected to a server to access information.
N
t
o
The end user will use the computer to access the Internet via a secure connection that
allows for encryption of client data. Encryption refers to the conversion of plain text into
encrypted data by scrambling it using a code that masks the meaning of the data to any
unauthorized viewer. Computers encrypt data by using algorithms or formulas. Encrypted
data are not readable unless they are converted back into plain text via decryption. This
prevents unauthorized persons from associating sensitive personal information with the
identity of specific individuals.
October 2004
U
20
D
SCCCR Collaborative – Requirements Document
The encrypted data flows over the Internet to a secure central local where HMIS are
centrally stored. Prior to access the central storage facility, encrypted data must negotiate
a firewall. A firewall is hardware and/or software system that enforces access control
policy between two networks.
After successfully traversing the firewall, client data is then unencrypted and organized
into logical tables and fields determined by the specific HMIS software solution. This
organization occurs at the application server level. The application server is simply a
computer with an HMIS software program that allows users to accomplish specific types
of tasks or transactions.
y
b
H
Finally, client data is stored in a central database. The central database can be encrypted
itself, can be located in secure or undisclosed locations, can be duplicated or mirrored to
allow for emergency back-ups of data. Many additional security measures can be
implemented at the central database level to limit access and/or monitor who has
accessed the database and the changes or additions made by each user to the HMIS
central database.
Figure 3.1
d
e
s
r
o
d
n
E
W eb Based Security M odel
Com puter
SSL
Encryption
d
e
v
r
o
SSL
Encryption
Firewall
ro
Application Server
Database Server
p
p
N
o
A
t
October 2004
U
21
D
SCCCR Collaborative – Requirements Document
Client Privacy Policies
In addition to technology approaches, many policy level measures are necessary to ensure
privacy. The most basic policy level consideration is the development of a complete
policy and procedure guideline that outlines the standard operating procedures for the
HMIS system. The policy and procedure document should indicate how the system is
intended to operate, the roles and responsibilities for end users and participating agencies,
and any requirements for participation (including training).
Examples of categories of policies and procedures that will need to be developed include
the following:
Username and password cannot be left in public view.
Passwords must be alphanumeric.
All staff must attend mandatory training.
Access is based upon the need to see, add, and/or change data.
The community must develop acceptability standards for data quality and system
use.
The community must develop client consent protocols.
Who should have access to client, program, agency, and aggregate information
and under what circumstances that access is granted.
Determine who owns the data.
Identify penalties for unauthorized access to data and misuse of data.
d
e
s
r
o
d
n
E
y
b
H
Many communities have already struggled with these issues and developed
comprehensive approaches to HMIS standard operating procedures. The SCCCR
Collaborative should review these existing information sources as efforts are undertaken
to develop an SCCCR specific approach to HMIS policies and procedures.
r
o
Recommendations
Obtain a lawyer or legal consult to assess laws around data sharing (HIPAA).
Review the HUD Data and Technical Standards and incorporate these standards
into the SCCCR HMIS system.
Continue to assess additional security features and function as it relates to selected
software implementation.
Develop a set of Standard Operating Procedures (SOPs).
o
r
p
t
o
d
e
v
p
A
N
October 2004
U
22
D
SCCCR Collaborative – Requirements Document
Part 4: Systems Integration Policies
Systems Integration Overview
Systems integration refers to the need in some communities to integrate data from
multiple different sources. This integration might occur at several different levels. For
instance, integration might be a consideration from a single provider source into a
community’s CoC database, from one CoC database to another CoC database, or
integration from one system (HMIS) to another completely separate system (e.g.
statewide social service tracking system). Systems integration can involve the migration,
merging, or integration of data from several different systems in order to generate an
unduplicated count of persons served or for purposes of research and analysis.
y
b
H
Several planning questions or considerations can help a community define their
integration needs and outline potential integration standards and strategies. The
following questions were introduced to the SCCCR Collaborative during multiple
community meetings throughout the planning process:
What data collection or data management systems currently exist on a
community-wide level?
How many and what specific agencies currently operate an existing data
management system to support their operation?
What are the goals of merging or migrating data from one system to
another?
Who should be involved in the planning or decision making process for
system integration?
Where will the data be merged, stored, managed?
How and at what level will the systems be integrated?
d
e
v
r
o
d
e
s
r
o
d
n
E
Many providers have multiple funders and different systems for tracking grants, clients,
and managing agency operations. An integration plan will need to address multiple data
collection systems and reporting requirements and coordinate the potential uses of
multiple local systems. Although the technological solution for systems integration can
be somewhat basic and standardized, the level of coordination and understanding of
multiple systems requires concentrated attention.
o
r
p
N
p
A
Many communities facing systems integration issues often establish a technical planning
group comprised of sophisticated users of the systems and technical experts to ensure
effective integration and successful communication between users of data and the more
technical manipulators of data. The first order of tasks for a systems integration technical
planning group is the identification of required integration levels, followed closely be the
establishment of standards for producing merged or integrated data. The following four
levels describe multiple types of integration considerations:
t
o
October 2004
U
23
D
SCCCR Collaborative – Requirements Document
Level 1 – One-Time Migration Recommendations
This refers to the one-time migration of data from one agency database to a communitywide HMIS system. In level 1 migrating agencies must be willing to bring their data to
the new system while simultaneously abandoning use of their old or legacy system. If
desired, all data elements from the legacy system are assigned to their most appropriate
data field in the new system and then, using a communication protocol to map the
migration of data, the contents of the old system are “sent” to the new HMIS. Providers
assume use of the new HMIS as their sole data management system and/or automated
solution.
• Identify from technical surveys the agencies that fall under the category of
“potential for migration”.
• Develop rationale for the benefits of migration.
• Develop a migration agreement protocol.
• Develop a migration technical standard for agency data download.
• Develop a standard and tool for agency data upload to the HMIS.
d
e
s
r
o
d
n
E
y
b
H
Level 2 – Agency-Level Integration Recommendations
Agency-level integration refers to the periodic integration or sending of data from an
agency that continues to operate their own system to a community-wide HMIS. In this
integration instance, typically a separate database can be produced from an agency’s
existing system and uploaded to the HMIS system. This solution is particularly attractive
to agencies that desire to participate in the community HMIS but do not want to give up
the autonomy and independence of maintaining their own agency-specific database.
• Identify from technical surveys the agencies that fall under the category
“periodic upload”.
• Develop a data upload agreement protocol.
• Develop a technical standard for periodic agency data uploads.
• Ensure that the agency standard and tool for agency data upload handles
periodic processing.
Level 3 – HMIS-Level Integration Recommendations
HMIS-level integration refers to the integration of different HMIS systems. This option
is especially important to the SCCCR Collaborative because of the existence of five
separate CoC planning entities within the Collaborative. HMIS-level integration
solutions allow each separate CoC jurisdiction to maintain their own systems but also
participate in research and analysis on a region-wide basis.
• Identify from technical survey responses the agencies that fall under the
category of “current HMIS users”.
• Use the integration standard for data uploaded into the SCCCR Collaborative
HMIS to communicate with HMIS venders participating in the collaborative.
• Develop protocols and mechanisms for HMIS developers to engage in the
customization of their upload/download tools.
• If only one agency operates a commercially available HMIS, regard it as agency
level integration.
o
r
p
t
o
N
d
e
v
r
o
p
A
October 2004
U
24
D
SCCCR Collaborative – Requirements Document
Level 4 – System-Level Integration Recommendation
System-level integration refers to integration of data within an HMIS system and other
non-HMIS systems such as Department of Health and Human Services client tracking
systems that manage public assistance benefits. System-level integration is highly
complicated and not a consideration for implementation within the SCCCR Collaborative
at this time.
• It is not recommended that system-level integration be attempted until HMISlevel HMIS systems are in place and functioning.
Figure 4.1
Integration Levels under the Initial Structure
Regional
Server
d
e
s
r
o
d
n
E
Periodic
y
b
H
Level 3
HMIS
County/COC
Server
County/COC
Server
Periodic
Agency A
Agency F
Level 2
Agency
Agency 10
r
o
County/COC
Server
Agency A!
Level 1
One time
C B5
Agency
Recommendations for Phasing in Integration Activities
The implementation strategy for integration should also be phased-in. The suggested
integration strategies are presented in chronological sequence. Figure 4.1, Integration
Levels under the Initial Structure, is broken down into phases and described below.
•
•
N
t
o
o
r
p
d
e
v
Phase 1: Standard and process.
o Develop the standard. This is essentially a categorized list of data elements
and procedural steps.
Phase 2: Level 1, One-Time Migration
o Target migration sites. Whenever possible, include as many integration
sites in this category.
o Develop data upload tool for migration purposes and pilot it.
o Implement the migration process.
Phase 3: Level 2, Agency-Level Integration
o Extend the functionality of the data upload tool to include periodic agency
data uploads and pilot it.
o Implement the periodic agency data upload process.
Phase 4: Level 3, HMIS-Level Integration
p
A
•
•
October 2004
U
25
D
SCCCR Collaborative – Requirements Document
o Work with participating HMIS vendors on multiple HMIS data
download/upload.
o Pilot each case individually.
o Implement case by case.
Decision and Communication Strategy for Integration
The SCCCR Collaborative will need to configure a working group committee to design,
recommend and oversee the implementation. This working group must identify a core
technical team willing and able to develop and test an integration tool that brings data
into the HMIS. This technical team will work with HMIS developers who will develop,
test and implement their system’s integration programs according to the pre-defined
integration standard.
d
e
s
r
o
d
n
E
y
b
H
These HMIS developers can be categorized into three groups. The first group is
characterized by an agency data user who is responsible for producing reports and
maintaining a local data system. In this type of agency there are no agency MIS personnel
per se and computer applications are rather simple. The second group is characterized by
the existence of agency MIS personnel. These are technically sophisticated agencies that
will chose to retain their existing system but are willing to collaborate by periodically
uploading client-level data to the HMIS. The third group represents developers of
commercially available HMIS tools used within the collaborative. Once the work of the
technical team and HMIS developers is completed and tested, a technical assistance
group takes on the responsibility of conducting the operational effort of implementing the
integration standard by taking one agency at a time. This technical assistance team also
has the burden of coordinating the actual implementation effort with agencies.
o
r
p
t
o
d
e
v
r
o
p
A
N
October 2004
U
26
D
SCCCR Collaborative – Requirements Document
Part 5: Where to Go from Here
Many additional planning discussions concerning specific software selection,
implementation, costs associated with HMIS planning, implementation, and operation,
and ongoing evolution of SCCCR Collaborative structure will need to take place in the
coming months. This section provides next step recommendations for software selection,
implementation activities, and increasing technical capacity.
H
y
b
Software Selection
Most communities that are selecting software for HMIS undertake a careful and
intentional selection process to ensure that the eventual software solution is one that
meets that needs of the community. The SCCCR Collaborative has developed an RFP
for such decision making and outlined a process for software selection. This
Requirements Document will be helpful in developing a list of criteria for HMIS vendor
evaluation and software selection. It is critical that the SCCCR Collaborative develop
clear and objective criteria for software selection since many software solution providers
will submit very different responses to the RFP. Typically an RFP describes the
implementing community, the leadership structure and context of decision-making, and
any decisions that have been made about software selection and system design that will
aid software providers in developing their responses. As of the writing of this Report, the
SCCCR Collaborative has developed a software selection RFP and defined a process for
evaluating respondents and selecting finalists.
r
o
d
e
s
r
o
d
n
E
Implementation
As part of the community-based meetings subsequent to the May 5 HMIS conference,
participants discussed implementation strategies for the HMIS system. Implementation
planning served as a logical extension of the community discussions regarding HMIS
operational structure and technical consideration topic areas. Implementation is
especially important in light of the decisions being made concerning the infrastructure of
the system and the need for systems integration among separate CoC HMIS systems.
o
r
p
d
e
v
Because the SCCCR Collaborative has such a wide range of programs, large number of
users, and an extensive geographic area to cover, implementation strategies needed to be
addressed on several levels – the collaborative level, the system level and the provider
level. Many of the decisions concerning the infrastructure of the overall SCCCR
Collaborative system had not yet been answered, thus this discussion focused primarily
on the local (individual jurisdictions) system and provider implementations.
Recommendations from part 4 of this report cover how the collaborative HMIS as a
whole will be structured.
N
t
o
p
A
Agency Implementation Recommendations:
• Develop standards for the system-level implementation including strategies for
jurisdictions starting from scratch and those migrating from existing HMIS
systems.
October 2004
U
27
D
SCCCR Collaborative – Requirements Document
•
•
•
•
Defined standards for agency-level implementation including those starting from
scratch and those migrating data from a legacy software system.
Agencies should begin developing sharing agreements (if they are sharing),
changing intake forms to address agreed-upon minimal data elements, identifying
lead staff and users and developing a plan for system migration (if necessary).
Provided a check list of issues that should be addressed at the agency level in
order to proceed with implementation.
Provided time for provider feedback concerning implementation strategies that
would best meet their needs.
H
y
b
System Implementation Recommendations:
The overall consensus of the participants in the community based sessions was that a
hybrid approach to implementation, as described above, would be the best option for the
system-level implementation in each jurisdiction. The next steps are as follows:
• A more detailed and refined technical survey must analyze willingness to pilot,
system integration needs and staff training needs.
• Survey responses should be carefully analyzed (maybe entered into a database)
and resources should be allocated accordingly.
• A system-level implementation plan for each jurisdiction should be developed and
include the first year of implementation. This would include the number of
programs, users, and the time frame for each program to come onto the system.
• Pilot programs should be identified by October 1 in order to provide the
maximum time for those agencies to prepare to implement. Pilot agencies should
be geographically and programmatically diverse in order to ensure coverage and
testing of all modules and features within the selected software system.
• System integration needs at the system and agency level should be identified and
a plan developed to address those needs. Provide examples of how system- and
agency-level strategies can be tailored to meet the needs of the community,
illustrating that a hybrid approach is often the most beneficial for the community.
• Beginning in October 2003, plan for quarterly check-in meetings with a neutral
third party (TA team) to assess progress and identify any emerging technical
assistance needs as software selection and system implementation take place.
o
r
p
d
e
v
r
o
d
e
s
r
o
d
n
E
Technology Capacity
N
p
A
Continuing Education Recommendations:
• Conduct HMIS 101 education sessions on a quarterly basis to ensure that all
levels of staff as well as consumers have the opportunity to hear about the basic
concepts behind HMIS and to understand the potential benefits of the system.
Education session should be offered for the remainder of the planning period as
well as during the pilot phase of implementation.
• Adapt HMIS 101 to include specific information on the SCCCR vision, mission,
technical considerations, and status of the planning process and decisions that
have already been made by the planning committee.
t
o
October 2004
U
28
D
SCCCR Collaborative – Requirements Document
•
•
•
•
Be clear with staff and consumers about who the decision-makers are for their
community, and provide some time in HMIS 101 sessions to hear feedback and
concerns from newcomers to the process, even though these concerns may have
already been shared by others who have participated in the process for a longer
period of time.
To minimize fear and concerns that may effect case manager and consumer
participation, develop and provide to all HMIS 101 participants a Fact Sheet or
FAQ sheet to take with them. This way, they will be able to refer to something
when questions arise that they were not able to discuss in the session.
Use HMIS 101 as a tool for developing further interest in the proposed system at
both the provider and community levels. As success happens, incorporate
information on those successes into the discussion.
Recognize within the discussion that directors often have different perspectives
than front-line workers, and provide information that will be pertinent to both
audiences. In other words, adapt the HMIS 101 discussion to include sections on
“how will this affect me?” issues.
d
e
s
r
o
d
n
E
y
b
H
Overall, the HMIS 101 concept should be included as part of the ongoing planning and
implementation process, but should be considered a working guideline that changes as
decisions are made and successes happen. It should be tailored for the specific
community as well as to meet the needs of the newcomers who will likely attend these
sessions. Not only should it provide some level of comfort for those attending about the
overall HMIS concept, but should provide specific-enough information and written
materials such that participants feel confident in participating in the proposed HMIS.
r
o
Additional TA Needs Recommendations:
The follow areas represent topics which might continue to provide difficulty for the
SCCCR Collaborative. Additional technical assistance (TA) resources are available for
continued work in the following areas:
1. Finalization of the HMIS software selection RFP. Development of a process for
software evaluation and vendor selection.
2. Development of a Standard Operating Procedures document for the SCCCR
Collaborative.
3. Further development of system utilization characteristics (at the agency,
continuum, and collaborative levels).
4. Review of national best practices for cross-jurisdictional data sharing and
analysis.
5. Development of HMIS staffing and budgeting models.
6. Development of a HMIS Management Plan.
7. Trouble-shooting pilot phase of implementation.
o
r
p
N
t
o
d
e
v
p
A
Ongoing Planning
The SCCCR HMIS Collaborative is well on the way to establishing a regional HMIS
project that can serve as a national model for collaboration, effective community
planning, and solid HMIS development. In an effort to codify the efforts of the past year
October 2004
U
29
D
SCCCR Collaborative – Requirements Document
and ensure continued success, the SCCCR Collaborative will need to complete the
following planning tasks in the coming year:
1. Formalize the SCCCR Collaborative partnership by develop a written
memorandum of understanding (MOU) among all collaborative partners. The
MOU should institutionalize the roles and responsibilities for each partner and
serve as the foundation for the HMIS Standard Operating Procedures.
2. Develop a clear and consistent communication plan to share HMIS updates and
planning items with all participating partners within the SCCCR Collaborative
jurisdictions. Each provider should know their role, expectations for their
involvement in HMIS, timelines associated with HMIS implementation, and
where to go for answers to questions or concerns.
3. Develop a “change management” plan for HMIS implementation that assists
providers with all training, acclimation to a new HMIS vendor, cost
considerations, staffing, timeframes, and “cultural” shifts associated with
automation and technology improvements in the not-for-profit sector.
o
r
p
t
o
d
e
v
r
o
d
e
s
r
o
d
n
E
y
b
U
H
p
A
N
October 2004
30
D
SCCCR Collaborative – Requirements Document
Appendix A: Description of TA Deliverables
Planning Process
The nature of the regional HMIS structure outlined by the SCCCR Collaborative presents
unique challenges for HMIS system planners. The planning area is geographically large,
includes multiple independent political jurisdictions all at slightly different stages in their
own independent HMIS planning, and involves hundreds of different homeless service
agencies each with different functional needs and uses for HMIS. In an effort to outline a
collaborative strategy for HMIS development, implementation, and management,
members of the SCCCR Collaborative requested technical assistance (TA) resources
from HUD to undertake a community-wide HMIS planning process that would result in
the development of a Requirements Document. The Requirements Document would
serve as a technical guide for the community, describing technical design specifications,
management strategies, and functional and operational considerations for a regional
HMIS structure. This Requirements Document is intended to assist the SCCCR
Collaborative in their selection of HMIS software and ongoing development of a regional
HMIS structure.
d
e
s
r
o
d
n
E
H
y
b
SCCCR Collaborative members, along with HMIS consultants hired through Aspen
Systems Corporation, outlined a package of TA deliverables that would assist the
community with HMIS planning and result in the development of a Requirements
Document for the SCCCR Collaborative.
The set of TA deliverables includes the following:
r
o
Sub-Task 1 Development of HMIS education materials for dissemination throughout
the collaborative with the goal of increased education about the benefits, uses, and
implementation of a collaborative HMIS for the providers, homeless service consumers
and intermediaries throughout the SCCCR Collaborative.
d
e
v
Goals of Sub-Task 1
1. Address education needs concerning the benefits, goals, and technical
considerations of an HMIS.
2. Promote leadership role of the SCCCR Collaborative on HMIS issues throughout
the community.
3. Establish a foundation of understanding of HMIS issues among the members of
the HMIS collaborative community.
4. Promote effective partnerships within the SCCCR Collaborative.
o
r
p
N
t
o
p
A
Aspen consultants developed education materials that reflect the basic information and
benefits of HMIS. Definitions, congressional mandate, standard technical considerations,
and HMIS planning were highlighted. The materials were developed into PowerPoint
slides, a brochure, and an outline for presentations by SCCCR Collaborative members.
Providers and homeless consumers who have limited knowledge of HMIS are the
intended audience.
October 2004
U
31
D
SCCCR Collaborative – Requirements Document
Aspen consultants conducted five pre-conference workshops throughout the Los Angeles
metro area to present the education materials, answers basic questions about HMIS, and
promote the communitywide conference held on May 5, 2003.
The objective of this level of TA is to facilitate large-scale education of the community
using members of the SCCCR Collaborative Steering Committee rather than outside TA
providers, promoting local control and ownership of the HMIS planning process.
d
e
s
r
o
d
n
E
y
b
Goals of Sub-Task 2
1. Initiate and promote a community-planning process for HMIS development.
2. Conduct a single HMIS meeting for broad-based community participation rather
than multiple smaller-scale meetings in numerous jurisdictions throughout metro
LA.
3. Establish working groups across topical areas rather than geographic areas to
assure cross-jurisdictional collaboration.
The conference jump-started the planning process by leveraging the existing education
campaign into a full fledged community planning process, culminating in the
development of a SCCCR Collaborative system requirements document.
r
o
SCCCR Collaborative members coordinated the HMIS conference, engaging all
interested providers and homeless consumers in active participatory planning. The first
half of the conference reinforced what was learned in the targeted community education
trainings, to provide a general overview of HMIS concepts and to provide an overview of
current implementation planning within the SCCCR Collaborative. The second half of
the conference provided structured break out sessions in topical areas such as: a) client
confidentiality and data security; b) systems integration; c) consumer involvement; d)
data sharing e) data reporting; and f) technology 101.
o
r
p
d
e
v
Sub-Task 3 Following the HMIS conference, HMIS TA was provided to each
Continuum of Care planning area to facilitate engagement of service providers in the
topical areas outlined in the conference agenda.
N
p
A
Goals of Sub-Task 3:
1. Provide targeted TA within specific topic areas to support the community’s
development of a meaningful HMIS requirements document.
2. Promote cross-jurisdictional collaboration in topical areas chosen by
community members from the list developed at the HMIS conference.
3. Produce a requirements document for the SCCCR Collaborative HMIS.
t
o
October 2004
U
H
Sub-Task 2 Organization and provision of a comprehensive HMIS one-day conference
for all homeless providers and interested consumers, initiating a broad-based community
planning process for the development of the SCCCR Collaborative HMIS Requirements
Document.
32
D
SCCCR Collaborative – Requirements Document
National HMIS experts, contracted consultants through Aspen Systems Corporation, with
experience in the implementation and management of HMIS systems across the country
facilitated work group meetings to solicit feedback from providers and clients of
homeless services in potential HMIS topic areas such as:
• Client confidentiality and data security
• Systems integration
• Multi-continuum of care collaborations
• Introduction to HMIS technology
• Consumer involvement
• Data sharing and reporting policy development
H
y
b
Aspen TA providers conducted five follow-up planning meetings in each of the HMIS
topic areas. These facilitated meetings enabled consultants to clarify community
positions on the topical areas, leading to the development of a requirements document.
d
e
s
r
o
d
n
E
Sub-Task 4 To inform its implementation of a community-wide homeless information
management system, the Los Angeles/Orange County Collaborative is interested in
identifying and understanding successful models for collaboration on information
technology. Sub-Task 4 of the TA presents descriptions of how other jurisdictions
around the country have implemented an HMIS in their communities. The document
highlights “What Works” in six communities – examples of decisions and practices that
can help inform the LA-OC HMIS decision-making process.
o
r
p
t
o
d
e
v
r
o
p
A
N
October 2004
U
33
D
SCCCR Collaborative – Requirements Document
Appendix B: Data Management Issues
Prior to the HMIS conference on May 5, 2003, the SCCCR HMIS Steering Committee
made decisions about reporting that will affect HMIS management:
• The system will produce client-level reports for service tracking and case
management;
• The system will produce aggregate-level reports for research, analysis, and funder
requirements;
• The SCCCR HMIS Collaborative will create appropriate methods or vehicles for
system-wide data release of aggregate information (websites, press releases,
reports, public presentations, etc.);
• HUD will release a report on data standards for HMIS. The community will use
that document to implement basic and compulsory data management strategies for
the community with each CoC jurisdiction reserving the right to expand on the
required set of collaborative-wide data requirements for their own needs.
d
e
s
r
o
d
n
E
H
y
b
The reporting session at the May 5th HMIS conference focused on four primary questions
and offered participants the ability to identify the issues and/or concerns that they had and
recommend solutions based upon other HMIS or MIS models. The four questions
included:
1. What are the standard reports that the HMIS will need to generate?
2. What are potential data analysis, monitoring, and research reports needed by the
Collaborative?
3. What are the standard elements (data variables) that comprise these reports?
4. How will the HMIS reporting process be managed?
r
o
The session encouraged participants to begin to consider how data should be organized
for reporting purposes and how reporting functions should be managed. The system
needs to be implemented with flexibility around data retrieval to allow connecting
agencies to track, manage, and analyze client-level and programmatic information,
however the technical infrastructure should include as many security mechanisms as
possible and policies and procedures need to be developed to account for human actions.
Participants felt strongly about the need for training of all users of the system, not only on
the system itself, but on the policies and procedures involving data access, retrieval, and
interpretation.
o
r
p
d
e
v
p
A
The following notes were summarized from discussions that took place in the reporting
training sessions held at the HMIS conference on May 5th and in subsequent community
meetings throughout the Collaborative region.
t
o
N
October 2004
U
34
D
SCCCR Collaborative – Requirements Document
Data Management – Reporting Matrix
WHAT STANDARD REPORTS
WILLTHE HMIS NEED TO GENERATE?
Reporting Needs
•
•
•
•
•
Ability to generate funder reports
• All federal reports (HUD APR)
Reporting function must be flexible and
• All state reports (Prop 10, EHAP)
easy to use
• All local city and county reports
Ability to generate outcome reports
• Client Served Summary
Reporting must be enabled at the client,
• Financial reports
program, and agency levels within
• Case management reports
agencies and aggregate community
reports for like-clients and like-programs
Ability to create unique and specific
reports and then replicate them over time
WHAT STANDARD REPORTING ELEMENTS
ARE PRESENT IN REQUIRED REPORTS?
Point-in-time (fixed)
• Name
• Date of birth
• Social Security Number
• Gender
• Race
• Veteran status
• First contact date
• Assessment date
• Intake date
• Program enrollment date
• Move in date
• Exit date
• Exit action
• Outcome of service
• Household configuration
• Household members
o
r
p
t
o
U
Standard Reports
d
e
v
d
e
s
r
o
d
n
E
y
b
H
Experiential (changing)
• Homeless status
• Income
• Disability status
• Health status
• Services provided
• Case management data
r
o
p
A
N
October 2004
35
D
SCCCR Collaborative – Requirements Document
MANAGEMENT OF DATA REPORTING
Issues/concerns
•
•
•
•
•
•
Recommended Solutions
Immediate access to agency, program,
and client level data
Ability to assign access to reports at the
agency level and program level
Clients own their individual data and
have the right to request electronic files
Legal liability
Monitoring and auditing of who is
generating reports
Consumer involvement in process very
helpful to ensure end product doesn’t
hurt consumers
•
•
•
•
•
•
•
•
Software solution must have flexible
reporting capabilities to determine
report structure, access, and reliability
Create group access levels
Internal protocols
Acceptable use
Mitigation policies
Mandatory training
Disclosure of reporting policy to clients
Client’s request for copy of electronic
files (process/protocol)
Process/protocol for clients that do not
agree to share information
d
e
s
r
o
d
n
E
•
y
b
H
HOW SHOULD AGGREGATE DATA BY ANALYZED, INTERPRETED, AND
PRESENTED?
Issues/concerns
•
•
•
o
r
p
t
o
Recommended Solutions
Misuse of information
Access levels to data
Who decides what aggregate level data
can be released and who can interpret it
d
e
v
r
o
•
•
•
Access on “need to know” basis only
Connecting Agencies control their own
data
Aggregate information managed by the
HMIS Authority
p
A
N
October 2004
U
36
D
SCCCR Collaborative – Requirements Document
Appendix C: Data Security Concerns
The following notes were summarized from discussions that took place in security
training sessions held throughout the SCCCR Collaborative region from January through
August of 2003.
U
Privacy, Security, and Confidentiality Decision Matrix
WHAT TECHNICAL SECURITY MEASURES ARE
NECESSARY TO ENSURE PRIVACY?
Issues/concerns
•
•
•
•
•
Recommended Solutions
Need for an audit trail
Hacking
Monitoring
Auditing access
Is VPN (virtual private network) a viable
solution for HMIS?
•
•
•
•
t
o
y
b
Firewall
SSL encryption
Username/password access
Audit trail
Ensure control of internal access “need
to know” basis
• Physical security
• Screen filters to enable limited viewing
of information
• Disaster recovery/backup
• Timeout
• IP filtering
• Redundant servers
WHAT POLICY LEVEL SECURITY MEASURES ARE NECESSARY TO ENSURE
PRIVACY?
Issues/concerns
•
•
•
•
•
•
•
H
r
o
HIPAA
Laws that affect the sharing of
information for sub-populations
o Health
o Mental health
o Substance abuse
o HIV/AIDS
o Domestic Violence
o Youth under 18
Minimal requirements for agency, user,
protocol
Legal liability
Monitoring and auditing
Consumer involvement in process very
helpful to ensure end product doesn’t
hurt consumers
o
r
p
p
A
d
e
v
d
e
s
r
o
d
n
E
Recommended Solutions
•
•
•
•
•
•
•
•
•
•
•
Not leaving username and password in
public view
Password should be alphanumeric
Group access level
Internal protocols (firewall rules)
Acceptable use
Mitigation policies
Mandatory training
Background checks for staff
Disclosure policy
Clients request for copy of information
(process/protocol)
Process/protocol for clients that do not
agree to share information
N
October 2004
37
D
SCCCR Collaborative – Requirements Document
WHO HAS ACCESS TO CLIENT-LEVEL DATA, AND UNDER WHAT CIRCUMSTANCES?
Issues/concerns
•
•
•
•
•
Misuse of information
Access levels to data
What decides what aggregate level data
can be release and who can interpret it
How can Domestic Violence providers
participate with safety, comfort, and
security
How can we ensure accurate
information?
o
r
p
t
o
Recommended Solutions
d
e
v
r
o
•
•
•
•
•
Access on “need to know” basis only
Aggregate information (identified or deidentified)
Access levels (read, write, edit, etc)
Real time or periodic data (timeframe
issue)
Legality
d
e
s
r
o
d
n
E
y
b
H
p
A
N
October 2004
U
38
D
SCCCR Collaborative – Requirements Document
Appendix D: Implementation Concerns
Community Concerns
Several concerns and strategies to address those concerns were discussed during the
community-based sessions throughout the planning process. The following table
highlights those discussions.
Implementation Decision Matrix
Concern/Issue Raised
Strategy to Address Concern
What technical capacity exists to
SCCCR Collaborative has developed a self-assessment tool for
implement HMIS at the agency
agencies to use, which is available on the LAHSA web site.
level?
SCCCR Steering Committee members will follow-up with HMIS
implementing agencies to assess technical capacity and to
understand what the needs are in each community for software,
hardware, connectivity, staff training, number of users, and
integration needs.
How can we meet the timeline in
The SCCCR collaborative will utilize a collective bargaining
the congressional directive?
model for the selection of software, and will attempt to gain
economies of scale for purchase of necessary equipment, training
and other implementation needs. The current implementation
timeline proposes to have an RFP released in the late summer
2003, a software package selected by late fall and implementation
beginning in communities throughout first 6 months of 2004.
Who will be hosting the data and
This system infrastructure question has not been finalized.
why (what is the infrastructure of
Specific recommendations will be made by in the Systems
the system)?
Integration section of this Report.
What assistance will agencies
Based on the responses to the technical survey mentioned above,
receive to prepare for
the SCCCR Collaborative and each jurisdiction will decide on
implementation?
financial and other assistance that will be made available to
agencies.
What model will each jurisdiction Based on the planning meetings that took place in each
use for implementation?
jurisdiction, it is clear that the best way to approach an
implementation this complex is to use a hybrid approach. Each
jurisdiction will identify 3-10 programs per continuum to
participate as pilot programs in the HMIS. These programs will
make recommendations at the end of the pilot period for system
improvement/enhancement. Each jurisdiction will begin a phasedin approach with the remainder of the agencies in the continuum.
Each agency will be responsible for developing an agency-level
implementation plan.
Who will be the pilot agencies?
Pilot agencies will be selected based on willingness to participate
(which will be a question on the technical survey) as well as the
need for geographic and program diversity among the pilot group.
Current readiness (staff capacity, existence of technology and
connectivity) will also be a factor in the selection of pilot
agencies.
o
r
p
t
o
d
e
v
r
o
d
e
s
r
o
d
n
E
y
b
U
H
p
A
N
October 2004
39
D