reach final submission scalability and sustainability · reach final submission – scalability and...

REACH Final Submission – Scalability and Sustainability Your app’s scalability, sustainability, completeness, and user experience will determine if it wins the grand prize. The judges will evaluate completeness and user experience when testing your final submissions. To judge scalability and sustainability, however, we will need you to summarize your plans. This form is your opportunity to explain how well and how quickly your app scales beyond Monmouth County, New Jersey and then persists as a free service to people across the country for ongoing use. ScalabilityScalability refers to how well, how quickly, and how completely your app serves people beyond the State of New Jersey.

a. Please explain how much of the country your app serves today. b. If your app has plans to serve more geographies after the competition, please explain your

strategy for achieving that scale, including how quickly it will occur and whether any capabilities of your app will not be scaled up.

c. Explain how your app will interact with the Homelessness Management Information Systems (HMIS) across the country at local Continuums of Care that use systems running on different platforms.

d. If you do not plan to use HMIS databases for shelter bed availability, please describe the strategy you use.

Please limit your response to 1,500 words.

How Much of the Country is Currently Served: To support the beta tests, Homeless Connections currently contains data about local services in New Jersey, Virginia and surrounding areas, along with some data describing nationwide services. Binary Group’s headquarters is located in Northern Virginia. The area has provided us a willing community of service providers and, due to its proximity to several military installations, Veterans for assessing and testing requirements during our software development process. Strategy for Expanding Geographic Coverage: Team Binary will partner with the VA and HUD to develop the most effective plan for expanding geographic coverage. That said, Homeless Connections has been specifically designed for rapid expansion to other locales. Our expansion plan calls for an “outside‐in” design approach that starts by understanding the needs, rules and constraints of a regional service community and the people they serve, rather than just examining the data. What we found using this approach in Monmouth County has reinforced our belief that a comprehensive, community‐driven solution is needed to really be successful at helping to end homelessness:

To help people out of homelessness, case workers across multiple providers need to plan collaboratively and in conjunction with the homeless, who ultimately have to be empowered to execute the plan.

To plan collaboratively and achieve the desired impact, both the community and those served need a much deeper understanding of each other, and the constraints under which service programs must operate. Today’s social service programs depend on

2

comprehensive rules to prevent fraud and abuse, along with frequent monitoring to assess progress and effectiveness.

Achieving enhanced understanding across the community will require an effective coordination, communication and change management initiative that results in increased collaboration, enabling everyone involved to maximize the value from adopting an empowering, self‐service, information sharing technology like Homeless Connections.

The regional coordination of care organization along with the community of service providers will have to ensure that the information being shared through the technology is both timely and accurate. There must be a clear incentive to take ownership tied to enhancing outcomes for the homeless that benefit the entire community.

Thus, adding a new locale involves a change management initiative to make the community aware of the Homeless Connections self‐service capabilities, requirements gathering to understand the rules and programs involved in the region, identifying accurate and appropriate sources of local service data, scraping data from those sources (described below), and engaging the community to curate the results and ensure quality, accuracy and timeliness. Willingness of service community leaders to use Homeless Connections functionality to enhance information sharing and coordination of care across the community, and extend their current HMIS may dramatically enhance adoption. Expansion should also be directly linked with the sustainability strategy and available funding, as further described below. Identifying and Tapping Data about Available Homelessness Services: Information about available services in a region must be mined from numerous Web sites whose structure and content is often inconsistent, poorly organized, and out‐of‐date. For example, during the contest we found and corrected inconsistent and duplicative data in local, regional and even national data sources (such as state 211 systems and even the VA’s database of accredited attorneys). Homeless Connections has built‐in functionality that automatically reads information from a wide range of social services Web sites, and structures it consistently. The frequency of this “data mining” can be controlled at a site‐by‐site level to ensure the data is as up‐to‐date as possible. Because the quality of the content on source Web sites varies so dramatically, it is sometimes not possible to get usable data from online directories. That’s why we believe it is so important that the service provider community keep their own service information accurate and up‐to‐date. Thus, in addition to the automated data scraping, we provide self‐service functionality that lets local service providers and regional coordinators view and update their information when the need occurs. When we find out about new service providers through data scraping, we provide these service providers accounts for making these self service changes. Developing data scrapers involves no software development and can be done directly by members of the service community. Given thirty minutes of initial training, each new data source can be scraped and tested in 15 minute or less. Based on our experience and accounting for time to find and validate the data sources, adding data for a new locale can be

3

done from scratch in a few days. Moreover, if a large data aggregation service like a 211 service already exists for a state or region, it may contain the bulk of the service information needed to mobile enable a wide range of locales, and the time required can be reduced significantly. Homeless Connections is currently hosted in the Amazon cloud. Performance enhancements for geographic expansion can be completed in a manner of minutes. Homeless Connections is built on an extensible software platform that has been deployed in a wide range of Government applications involving millions of user accounts and thousands of simultaneous users. User and database growth can be rapidly accommodated without new software development. Exchanging Information with Homeless Management Information Systems (HMIS): Since many service providers already work within the context of a local or regional HMIS system, it would streamline service delivery and reduce duplicate data entry if Homeless Connections could electronically exchange appropriate information about the homeless with the HMIS. For example, information gathered through the self‐service features of Homeless Connections (described below) could be passed electronically to the HMIS, and accessed securely by case workers in their daily work context. Duplicating data entry would be reduced, saving time for both the homeless and case workers. We plan to provide this interface through a data exchange mechanism that conforms to the HUD HMIS XML‐based information exchange standards, making it easy for the HMIS vendor community to readily use. As regional coverage is expanded, this information exchange functionality would need to be tested with the regional HMIS. Currently, a small number of HMIS vendors support the majority of the communities nationwide. Information exchange support could be tested and any issues resolved as new vendors are encountered during regional rollout, and should be accommodated in the scalability plan. Support for Real‐Time Service Coordination including Shelters: Our research and discussions with the service community in both Monmouth and Fairfax counties has indicated that providing real‐time shelter information may not be directly helpful to homeless clients. Due to regulatory and safety requirements, members of the local social services organization must act as brokers to coordinate shelter space for the homeless. Though Homeless Connections currently supports real‐time Homeless Management Information Sharing (HMIS) integration in Monmouth County for shelter availability, we don't believe that this specific support is required going forward, but it can be provided if needed. Homeless Connections contains a set of extensible mechanisms to directly help coordinate services between a homeless person who has a need and the full community of providers who serve that need:

1. Self‐assess their eligibility for services like shelter space that require coordination, and 2. Electronically coordinate and collaborate with social services organizations in a secure,

real‐time manner, regardless of the time or location, to speed up the process of applying for and receiving these kinds of services.

4

This approach leverages an advanced software technology known as dynamic case management in which the business rules driving these assessments and service requests are modeled visually and intuitively, not hard coded in software. The rules can be extended as required without change to the underlying application. Modeling and implementation can be done by the service organizations themselves as part of the regional change management initiative, rather than requiring the use of highly trained IT developers. This enables Homeless Connections to rapidly adapt to regional and jurisdictional distinctions in regulations. These mechanisms also provide a rapid coordination tool for the homeless, service providers working with them, and case workers working for both social service organizations and service providers. All can share information securely and in a timely manner so that the service need can be met as quickly as possible in compliance with regulations. In recent discussions, county social services organizations uniformly expressed that these Homeless Connections capabilities would significantly benefit both Government and non‐profit social service organizations by:

Providing self‐service functionality to augment limited hours and staff;

Better informing and serving clients who contact services after hours;

Allowing clients to find and pre‐screen services themselves;

Allowing clients to take a more pro‐active role in their care;

Capturing data only once, saving client and social services time;

Functioning as a training tool for new or less skilled staff, as it manages regulatory rules

and related decision logic;

Providing assessment functionality that case workers could utilize to help explore a

client’s unique needs.

Providing intuitive and accurate search capabilities, beyond keyword search found in

other offerings like 211 systems; and,

Providing automated case management capabilities for non‐profits that cannot

otherwise afford that automation.

SustainabilityThe goal of Project REACH is a free app that is widely available so that as many people as possible experiencing homelessness and working with the programs that serve the homeless can get help. Please describe how you plan to sustain your app long‐term as a free service after the contest ends. Judges will consider and evaluate whether your proposed strategy is practical and achievable.

Please limit your response to 1,000 words.

A Strategy for Sustaining Homeless Connections as a Free Service: The development, testing and delivery of the current Homeless Connections functionality as a free service for homeless Veterans in Monmouth County has been funded by Binary Group and its technology partner Be Informed. Our sustainment strategy depends on our ability to secure incremental funding as required for the following stages:

1) Initial deployment of the current functionality to two regions to validate the approach

5

in practice, identify key gaps and make those enhancements; 2) Expanded deployment of the enhanced functionality to ten regions to gain exposure to

a sufficient community base to understand and address regional differences and corresponding requirements while validating that the service can be self‐sustaining;

3) Enhancement of the functionality and value offered to enable self‐sustainment, followed by incremental scaling of the infrastructure and support staff (such as help desk capabilities) in a nationwide deployment.

Stage 1: Initial Deployment: For the first stage, our strategy is to secure a grant to refine the functionality of Homeless Connections and deploy it as a secure, cloud‐based shared service that extends two regional social service HMIS and/or 211 systems (according to the recently published figures, approximately 250 distinct US regions exist that are covered by HMIS and 211 systems currently exist). The purpose of the grant would be to validate the functionality required to effectively bridge the planning and coordination gap between homeless clients and local service providers in two regional areas. Enhancements to HMIS and 211 services have frequently been funded through grants from a variety of organizations, and also through the shared contributions of local service providers. In discussions with VA and HUD, we will assess the nationwide and regional homeless and Veteran programs that could best be served by the capabilities of Homeless Connections. This assessment will help better identify the homeless population each locale serves, and identify the most effective funding sources. An incremental deployment plan will then be developed addressing both expanded functionality and geography. We estimate that grant funds ranging from $1.8M to $2.3M would be sufficient to support the initial deployment stage. Stage 2 – Expanded Deployment and Validation: The second stage will expand the deployment to approximately ten selected regions to gather insights about regional differences and localized requirements, while testing the ability of Homeless Connections to be self‐sustaining as a free service to those in need. To be really self‐sustaining, Homeless Connections must offer enough value to service providers that they would be willing to pay a reasonable annual subscription fee for its use, particularly if costs are shared across a community of providers. To fund this stage, follow‐on grant funds, corporate sponsorships, and contributions from the ten local geographic areas would be sought to both deliver and clearly demonstrate these benefits to a representative set of communities and test out a variety of potential subscription models such as number of clients served or case workers supported. We estimate funding required for this phase to range from $2.3M to $2.7M, which includes the on‐boarding of ten new geographic areas. Stage 3 – Expanded Capabilities and Nationwide Adoption: The final stage will leverage the insights gleaned in Stage 2 to expand into a self‐sustaining, nationwide free service, incrementally expanding capacity to keep pace with community interest and adoption. New geographic regions can be on‐boarded for about $50,000 each…which we believe can be obtained from local contributions or sponsors in each

6

geographic area. To meet the goal of being fully self‐sustaining, the broader service will have to attract additional grants and bring in sufficient subscription revenues and other fees to cover sustaining engineering, operation and maintenance costs. Once the system is adopted, the yearly national sustainment costs are estimated to be $2.5M to $3.3M. We would anticipate targeting:

a) regional area providers/sponsors; b) HMIS or 211 system providers (whose products might be significantly enhanced by

subscribing to the service); c) National public interest grants to cover the annual sustainment program; d) Grants from computing and telecommunications industry players like Verizon, who

have donated generously to social service causes over the years, particularly when their products can make a substantial difference in the daily lives of the poor and disadvantaged; and,

e) Advertising revenues from Government and industry organizations for ad placement on the Homeless Connection application (similar to the Facebook model).

One area of enhanced functionality we believe can dramatically help promote and thus fund that adoption is support for more effective service planning. To help ensure integrity in the expenditure of public funds for social service purposes and entitlement programs, legislatures have put in place an increasingly comprehensive and complex set of rules to ensure that limited funds are being properly and effectively applied, and that needs are being met. Increasingly, case workers and the needy must establish and together follow and track the progress of service and care plans. The entire process is being required to become more and more transparent to ensure that public funds are not abused. Homeless Connections can meet this need head‐on by delivering adaptable, mobile‐enabled self‐service tools into the hands of homeless people and their case workers alike, so they can readily navigate the increased legislative and regulatory complexity. With enhancements that leverage its built‐in dynamic case management and activity planning capabilities, Homeless Connections can provide clients and case workers a means for collaboratively developing, revising and tracking the progress towards achieving their goals and service plans. Having a set of needs clearly identified for a specific population of homeless and being able to more effectively track how these are being fulfilled will enhance the ability of non‐profits to secure charitable contributions, and the ability of service providers to justify their own funding. Being able to clearly demonstrate and prove the value of these enhancements may provide the spark that lights a fire for nationwide adoption, and potentially the expansion of similar capabilities beyond homelessness to a wide range of Governmental programs.

1911 N. Ft. Myer DR, Suite 300

Arlington, VA 22209

Telephone: 571.480.4444

Fax: 571.480.4445

www.binarygroup.com

October 15, 2012

Robert Damashek, Chief Architect

Corey Brown, Software Engineer

ABinaryGroup Document

ResponsetoVAi2QuestionsonHomelessConnectionsScalability

Binary Group Proprietary and Confidential 2

TableofContents

1. Our Architecture – Designed for Technical and Functional Scalability ................................................. 3

1.1 Design Philosophy ......................................................................................................................... 3

1.2 Technical Architecture .................................................................................................................. 5

1.2.1 Cloud‐based, Scalable Hosting Technology ............................................................................. 5

1.2.2 Scraping Web‐based Service Directories ................................................................................. 6

1.2.3 “Real‐Time” HMIS Shelter Availability Feeds ........................................................................... 7

1.2.4 “Real‐Time” Job Offering Feeds ............................................................................................... 7

1.2.5 Data Synchronization Service ................................................................................................... 7

1.2.6 Dynamic Case Management Platform ..................................................................................... 8

1.2.7 Service Registry ........................................................................................................................ 9

1.2.8 Knowledge, Rule and Case Models .......................................................................................... 9

1.2.9 Model and Case‐Driven Activities .......................................................................................... 10

1.2.10 User Accounts and Self‐Service Portal ................................................................................... 10

1.2.11 Mobile Access Enablement .................................................................................................... 11

2. Data Sources ....................................................................................................................................... 11

3. Planned Application Enhancements ................................................................................................... 12


On 14 September 2012, we received via email questions to Binary's submitted plan for

scalability and sustainability. We have organized our responses to these questions into three

logical sections: Our Architecture, Data Sources and Planned Enhancements. Below in italics are

the original text/questions with references to our responses.

Please provide more information about your strategy for extracting data from many disparate sources and presenting it in your app. [Section 1.2.2] Please include details regarding how many data sources you are pulling from and how often you are pulling data. [Section 2] For example, submit a diagram of your technology stack, a written description of the processes, technologies and infrastructures that you will be utilizing, or any other product that helps explain your strategy. [Section 1.2] Please provide code snippets when possible and include details to make it clear whether you are using a data warehouse or directly pulling from the source for your app. [Section 1.2.2]

If you are using a data warehouse: [analogous answers provided below]

How will you ensure that duplicates are removed, and that the contents of your data warehouse are accurate? [Section 1.2.4]

How will you scale your data warehouse? [Section 1.2.7] How does your app connect to the data warehouse? [ Section 1.2.7] Please provide code snippets when possible. [Section 1.2.5] (Removed from final

submission per VA request)

How will your app ensure functional performance as you scale? [Section 1.2.1]

Will you be tracking information about app usage or about the app’s users? [Section 3]

Will you be tracking the information, location, and/or identity of the user? [Section 1.2.10]

In your scalability response you mention the ability to train a person in 30 minutes to be able to scrape and test new data sources. Would you be able to provide us with the 30 minutes of training? [Section 1.2.2]

1. OurArchitecture–DesignedforTechnicalandFunctionalScalability

1.1 DesignPhilosophyOur philosophy for Homeless Connections has been to design from "Outside In", i.e. start first

with, and organize around, fulfilling the needs of the app’s stakeholders – the homeless patron,

service providers, case workers, and administrators with whom they interact. Our “Outside In”

design approach places more attention on mastering the flow and ability to share information

using externally developed infrastructure. It is analogous to how one leverages the Internet by

building peer‐to‐peer, trusted relationships and networks to access needed information. This is


dramatically different from a traditional design, which starts with available data, translates the

data into a common technical form and then makes that data available to users. This traditional

design approach focuses on internal development such as storing data, and is based on an

“Inside out" philosophy. Our design philosophy helps us focus on helping the homeless

successfully get the services they truly need, rather than just delivering them information about

services they may or may not need, or be able to receive.

Several distinct business challenges drive our "Outside In" design, including:

1) Eligibility rules are complex and vary by community. For example, a homeless veteran

may be ineligible to receive service from a VA service provider due to their military

Service separation status but is eligible to receive service from a local non‐profit

organization. So while it’s relatively easy to find information about local services, it can

be daunting to sort through the usefulness of this information based on a person’s

unique individual needs. Moreover, eligibility is increasingly being constrained by multi‐

service plans established to ensure that limited public social service funds are not being

abused. The latter is increasingly becoming the #1 challenge for administrators

managing homeless programs. We have concluded from talking with the stakeholders in

the homeless community that an information referral service just won’t get the job

done.

2) The type and number of services available and useful to the homeless is continually

expanding and evolving. For example, the community is increasingly moving towards

services that help prevent homelessness via early interventions, in addition to

addressing homelessness after it has occurred. A design focused on empowering the

needs of the end user readily allows the introduction and adoption of new types of

services and new sources of providers, thereby increasing functional scalability.

3) An observation that data describing services applicable to the homeless is today found

in a wide variety of web‐enabled sources, each managed by different organizations and

communities, and governed by different regulatory mechanisms. The quality, duplicity,

structure, rate of change and underlying semantics of these data sources varies widely.

4) Search criteria for services to the homeless are implemented differently in different

registries. Bottom line, a centralized architecture such as a data warehouse that

supports nationwide usage will be difficult and expensive to create, populate and

maintain.

Our architecture design is based on connecting with distinct members of the community and

better coordinating their interaction and information sharing to drive more beneficial outcomes

for the homeless. Even though we apply extract, transform and load (ETL) techniques to gather


data, like traditional data warehouses and data marts, our technical architecture is NOT based

on building a data warehouse and then connecting the app to it.

1.2 TechnicalArchitectureWe employ a set of six COTS components and open frameworks in our technical architecture

stack, as illustrated in Figure 1. Reading the stack from left to right, and bottom to top, the role

and capabilities of each of these architectural elements are described below. The numbers

after each section heading correspond to the numbers in the dots in the diagram.

Figure 1 - Homeless Connections Technical Architecture

1.2.1 Cloud‐based,ScalableHostingTechnology To support application performance and technical scalability, Homeless Connections utilizes a

set of secure, cloud‐based JBOSS application server and Microsoft IIS web server instances

hosted by Amazon Web Services. For scalable data management, Homeless Connections

utilizes secure, cloud‐based Microsoft SQL Server instances hosted by Amazon Web Services.

The application currently uses a combination of JDBC and ODBC interfaces to connect with the

database.


These virtual servers can be scaled through clustering, and the application can be distributed

across these clusters to take advantage of regional infrastructures while providing 24‐7 failover

and recovery mechanisms. Although Homeless Connections is not currently deployed in this

manner for the contest, the Dynamic Case Management platform, Be Informed, is fully capable

of utilizing an n‐tier architecture supported by web service and service bus mechanisms to

further decouple component technologies and enhance technical scalability. This can be

implemented without any change to the functional application.

We estimate that by using these mechanisms, Homeless Connections can quickly scale to

support the full nationwide population of homeless people and the supporting service

community. Because of the flexibility of this architecture, it can be proposed as a Federal,

cross‐agency shared service to support similar social service needs across an even broader

population, to achieve even greater reuse and resource efficiencies, while enhancing

sustainability by reaching an even broader population of those in need.

1.2.2 ScrapingWeb‐basedServiceDirectories We gather descriptive data about services from a variety of sources (further described in

Section 2 below). Most of these data sources are specialized directories of services openly

available through the web. However, the content, structure and quality of these data sources

vary dramatically, making it very difficult to collect, standardize and integrate this data using

conventional data management technologies.

For each unique web data source, we have developed a data scraping agent to normalize the

content of that source, and make it available through our standardized service registry. We

utilize Mozenda, a COTS data scraper tool hosted in the cloud, to build and execute these

agents on a schedule appropriate to the nature of the data accessed and its frequency of

change. Agents are built by examining the web data content at a given web page, and

specifying the fields, structures and navigation mechanisms to scrape using an intuitive point &

click approach. When done, the agent can be tested and the results examined to ensure that

the expected information is being extracted in the format needed. The agent is then deployed

in Mozenda’s cloud‐based service, and scheduled to run at appropriate intervals to keep the

data up‐to‐date. Using this process, any data source can be added in minutes. We developed a

standard target template, allowing new service data sources and new types of services to be

identified and added into the service registry by members of the service community who are

best positioned to evaluate and resolve data quality issues.

We believe that this data scraping process is both intuitive and easy to use, and allows

responsibility for extending and maintaining the quality of the service registry to be delegated

to regional administrators or members of the service community skilled in data quality (e.g.


curators), which further enhances the functional scalability (and usability) of our solution. To

support the development of Homeless Connections, we have scraped a wide variety of local

and regional web data sources using non IT personnel. Binary welcomes the opportunity to

meet with the VAi2 staff to demonstrate and train them on the scraping process. We believe

this design feature is a key differentiator for Homeless Connections because it allows functional

personnel to take full responsibility of data quality, rather than depending on an IT staff to

perform this task.

1.2.3 “Real‐Time”HMISShelterAvailabilityFeeds In addition to the web data sources that are scraped on a scheduled basis, data on real‐time

shelter availability for New Jersey counties is made available in CSV file format on a near real‐

time basis from the New Jersey Housing and Mortgage Finance Agency. A software agent

examines the content of this file every 6 hours and creates an updated status feed to the Data

Synchronization Service. As discussed in our Scalability and Sustainability form submission to

VAi2, we will retain, but currently do not plan to expand this specific feed, since a “coordination

of care” process is required to obtain access to shelter space, and the real‐time data by itself is

not of specific value to the homeless. That said, we believe that in the future it would be

beneficial to support real‐time synchronization of Homeless Connections and HMIS data for

coordination of care activities, building upon the HUD data exchange standards. Our technical

architecture will support this process in the same manner as the real‐time shelter availability

capability, as a uni‐ or bi‐directional data exchange extension to the data synchronization

service described below.

1.2.4 “Real‐Time”JobOfferingFeeds Because of the large number of web‐based data sources that provide job offering data and its

timeliness, we decided to tap a number of representative sources that allowed the

establishment of subscriptions to RSS‐based data feeds. The use of RSS feeds enhances the

timeliness of the information shared. Through discussions with the service provider community

including Government employment assistance organizations, we determined that having access

to timely information about full‐time job offerings is not very helpful to those who are coping

with other difficult life conditions like substance abuse. We therefore extended our data

sources to include part‐time job availabilities and jobs targeted towards Veterans.

1.2.5 DataSynchronizationService We have developed a data synchronization service that uses .NET, C# and ODBC functionality to

read the automated data scraping output and merge it with our service registry. Largely for

convenience, this service currently supports scheduled, server‐based synchronization through

CSV files posted to a common server‐based directory. But the service could easily be adapted


into a Representational State Transfer (REST) service using Windows Communication

Foundation (WCF). We also support a web‐based mechanism that allows community

administrators to submit properly formatted data for intake into and synchronization with the

database. To enhance data accuracy, quality and timeliness, we also allow service providers

and curators (functional people who are responsible for data quality), to provide direct, self‐

service updates to data in the service registry. Over time, any online registry would be

expected to become out‐of‐date. By combining self‐service updates with enhanced

coordination of care and community feedback capabilities, we hope to encourage the service

community to keep this data up‐to‐date and relevant.

Since the data synchronization service must merge data extracted from a variety of disparate

web‐based data sources, it must also handle and eliminate duplicate or even conflicting data.

The automated web data scraper has some features to eliminate duplicate entries. The data

synchronization service also eliminates duplicate service data eliminated based on the

uniqueness of service type, provider name and location properties. Furthermore, the data

synchronization service guarantees that updates entered directly by service providers using the

Homeless Connections portal are given precedence over data scraped from web‐based sources.

1.2.6 DynamicCaseManagementPlatform A core element of our technical architecture is the Be Informed dynamic case management

platform, a COTS solution that has been deployed globally to over 50 customers. As shown in

the graphic on the left side of Figure 1, this Java‐based platform supports a number of common

open standards and interfaces with a range of other software components. As explained in

Table 1 below, the platform enables and empowers business subject matter experts to model

and rapidly evolve the rules governing the flow of activities in their business domain, such as

the eligibility rules that regulate the delivery of the social services based on the conditions in a

patron’s case. In Be Informed parlance, these are “Above the Line” activities that enable an

“Outside In”, user‐centric architecture. An inference engine inside of Be Informed dynamically

adapts the flow of activities to the unique needs of each user given the context and status of

their specific case. IT specialists then develop only the software‐specific models and interfaces

that drive how the application works “Below the Line” of user‐centric interactions and business

rules. This powerful architecture puts the functional scalability far beyond that of traditional

mobile applications or data‐centric solutions.

Table 1 - Comparison of Traditional and Outside-In Approaches

Component Traditional – Inside‐Out Homeless Connections – Outside‐In

Business Logic Hard coded into application, Modeled independently of software,


and Business

Rules

change requires software

development by IT professionals

community can maintain and evolve

rapidly

System Logic Hard coded into application,

change requires software

development by IT professionals

Modeled in application, change

requires model development by IT

professionals, can be tested and

deployed rapidly

Data

Management

Data‐centric, additional data

sources often require new ETL or

interface logic, data warehouses

hard to maintain and evolve,

requires development by IT

professionals

User‐centric, data captured from new

web data sources with rapid, point‐

and‐click interfaces, can be done by

service providers and community

service coordinators

1.2.7 ServiceRegistry The Homeless Connections service registry contains only the information about services and

service providers whose fundamental data structure is the most common and least likely to

change (e.g. name, location, service hours and contact information). Services are also linked to

a specific type of service, using an extensible service knowledge model (or ontology). Because

only a small, standardized amount of service‐specific data needs to be captured in the service

registry, our ETL, data quality and data integrity needs are correspondingly simplified, as

described in Section 1.2.2 above. Both the service registry and the models described in the

next section are supported by standard relational database management technology. We have

chosen to utilize Microsoft SQL Server because of its cost‐effectiveness, performance and

technical scalability characteristics.

1.2.8 Knowledge,RuleandCaseModels Central to our architecture is a set of common semantic models that allow us to represent

knowledge about the needs of our user stakeholders – the community of homeless people (we

call them patrons), service providers, case workers and services. We separate knowledge about

those needs from knowledge about how to fulfill those needs (including eligibility rules), and

from information describing available services.

Business Rules and regulations governing service eligibility are modeled in a separate rules

model. Each service type can have its own eligibility rules, while regional and/or local rule

variation is also supported. The rules are modeled, not hard coded into the application


software, and can be changed or extended without changing the application or its interface.

These rules can be viewed by anyone, and extended by authorized members of the service

community. With minimal training, these extensions can be developed and maintained by

business people, not IT or technical staff. The use of business people/expertise (those closest

to the situation), not IT/technical staff, is another unique element of our architecture that is key

to enabling functional scalability.

Finally, the homeless patron's unique goals, plans, needs and state are captured in a special

kind of adaptable knowledge model called a case.

1.2.9 ModelandCase‐DrivenActivities The flow of valid activities available to community members, such as the steps involved in a

specific eligibility assessment, is dynamically controlled by assessing the state of a patron's

unique case against business and eligibility rules. This approach, called “dynamic case

management” allows Homeless Connections to rapidly adapt to a wide range of variation in

local and regional eligibility rules, greatly enhancing both technical and functional scalability. In

deployed applications around the world, the Be Informed platform has been proven to rapidly

accommodate regulatory and rule variations governing government services on a national

scale, greatly improving quality of service to citizens.

1.2.10 UserAccountsandSelf‐ServicePortal Homeless Connections users are provided self‐service functionality through role‐specific

portals, allowing them to request new accounts, make changes to their accounts, coordinate

care, view the state of requests and cases, and provide feedback on both the services and

quality of care received. For the homeless patron, the portal provides a mechanism for service

providers to securely communicate with them in a timely manner, even when they don’t have a

traditional contact mechanism.

All service providers identified in the data scraping process are given accounts that allow them

to keep the data about their organization and services accurate and up‐to‐date. Service

providers can create and maintain case worker accounts for their staff. Patrons can create

accounts to make requests for coordination of care when services cannot be directly given

(such as those involving eligibility determination and placement). Case workers can also assist

in making these requests on behalf of patrons who specifically request that assistance.

We currently allow for both anonymous and logged in users, supporting self‐service accounts

for service providers, case workers and patrons. Patrons can provide case workers access to

their account information to perform searches and make service requests on their behalf.

When logged in, any changes made to either case content or the service registry is tracked for


historical purposes. In addition, some identifying information is maintained in a patron's case to

facilitate coordination of care. At present, precise geo‐location information is not maintained

beyond an application session.

1.2.11 MobileAccessEnablement The Be Informed platform provides a capability for extensible, mobile access. Data for user

interaction is exchanged via XML, and an XSLT‐based layout can be developed to tailor the XML

to the unique viewing and ease of use constraints of different mobile devices and platforms.

Homeless Connections uses these XSLT transforms along with jQuery Mobile to provide an

intuitive and friendly user interface that works well on almost any smart phone, tablet, laptop

or desktop.

2. DataSourcesThe initial Homeless Connection app has imported and integrated 35+ sources of data for

serving the homeless veteran population in 2 geographic locations: Monmouth County, NJ and

Fairfax County, VA. The services included in this release of Homeless Connections and their

update frequencies are shown below:

Data Type # of Sources Process Frequency

Emergency Shelters – Monmouth 1 Real‐time HMIS feed Every 6 hours

Emergency Shelters ‐ Fairfax 1 Scraper Agent Monthly

Transitional Housing – Monmouth 1 Scraper Agent Monthly

Transitional Housing – Fairfax 1 Scraper Agent Monthly

Clothing 3 Scraper Agent Monthly

Food – Food Banks & Soup Kitchens 9 Scraper Agent Monthly

Healthcare – General, Dental,

Mental, Substance Abuse

7 Scraper Agent Monthly

Employment Services 2 Scraper Agent Monthly

Jobs (full and part‐time) 6 RSS Feeds, Scraper

Agent

Every 6 hours


Legal 2 Scraper Agent Monthly

Transportation 2 Scraper Agent Monthly

Hotline 6 Manual On demand

3. PlannedApplicationEnhancementsIf Homeless Connections is funded for deployment, we will work with the homeless service

community to define an initial set of capabilities needed to support collaborative service

planning between the homeless and their case workers. These plans need to be

understandable to all participants, easy to design and rapidly change, yet fully capable of

tracking progress towards achieving goals in accordance with regulatory requirements. We

believe that our dynamic case management platform will enable all of these criteria to be met,

and will fill a critical missing gap in the overall drive to end homelessness. As discussed above,

we will work to leverage the HUD HMIS data exchange standards to enable real‐time

synchronization of Homeless Connections and HMIS data for these plans and other

coordination of care activities.

We have been testing a semantic analysis technology called the Semantic Insights Research

Assistant (SIRA) that could be inserted into the technology architecture to help with the

following two challenges:

1. Finding and categorizing useful, new web‐based service data sources as a research

assistant for curators; and,

2. Finding targeted services in the service registry given the full breadth of knowledge

about a patron and status of their case.

SIRA allows users to express their search needs using natural language (versus utilizing keyword

or database search techniques), finds relevant content in unstructured web content and data

sources through knowledge of language and domain semantics, and can render the search

results in an intuitive English form. To start, we are creating an initial demonstration of how

SIRA will address the second challenge.

Finally, we have tested and plan to use Google Analytics to track and report on the usage of

Homeless Connection upon expanded deployment. A security service that adheres to

Government‐standards for the necessary protection of any PII, including HIPAA rules, will also

be implemented.

reach final submission scalability and sustainability · reach final submission – scalability and...

Documents