REQUEST FOR DEVELOPMENT OF A WEB BASED RESOURCE DATA MANAGEMENT APPLICATION AGING AND HEALTH RESOUCES DIVISION

Transcription

1 REQUEST FOR DEVELOPMENT OF A WEB BASED RESOURCE DATA MANAGEMENT APPLICATION AGING AND HEALTH RESOUCES DIVISION Request for Development of a Web Based Resource Data Management Application Aging and Health Resources Division Project Overview ARC operates the aging and disability regional information and referral network and has developed an existing application, ESP that has reached the end of its useful life. The service and provider database content is very extensive and deep. ARC wishes to replace the existing application with a newer, more advanced application that will improve its information and referral process and increase efficiencies. ARC is soliciting proposals to design, develop and support a state of the art Information and Referral Database software application. This system will enable ARC to have a central repository of information about service providers and service programs. The application must be intuitive, supportable, scalable, and cost effective and have the foundation to support future growth. The application must be a web-based application that can be hosted or deployed locally on ARC servers or at a location of ARCs choosing. Integration to third party applications is critical. The application must provide a robust API to map data from other ARC and partner systems. These include but are not limited to: SAMS Client Tracking System Simply Get There Transportation System Salesforce CRM ARC requires specific functionality to model internal business processes, workflows, partner needs, and integration requirements. ARC will own the application and any appropriate licensing models. Third party license fees should be minimized. ARC has developed an extensive network of subscribers and may want to grow or extend the network over time. The greatest asset of ESP is data content. Subscribers may wish to access the information directly through an user interface or through an API into their own client system. Background: Current Data Resource Management Application Over 20 years ago, the Atlanta Regional Commission developed a software system to manage both clients and service data The Enhanced Services Program (ESP). Shortly after the 12 AAAs joined together to create a statewide resource database housed in the ESP program which currently totals over 26,000 services. Each AAA has provided staff support to manually maintain the individual service records on a set schedule giving the database a well-deserved reputation for highly accurate and relevant information. ESP is a vital tool for ARC counselors and third party subscribers. The content of the ESP database has been developed over a period of 20 years. ARC has multiple third party subscribers that utilize the ESP system and data to assist in making sound referrals to their consumers. They also pay a periodic subscription fee to ARC to utilize ESP.

2 ESP has three major user roles: 1. User internal ARC staff member who use the system on a daily basis to identify service providers and refer customers to appropriate services. Users do not recommend providers; only refer. Administrators are also grouped into this category; however, they have additional rights for data update and management. 2. Subscribers third party agencies that utilize ESP to identify services and providers for their customer base. Subscribers normally pay a fee to access ESP and its provider database. 3. Customers Outside customers that utilize the referral services from ARC or third party subscribers or access some basic resource information from a website tool. Scope of Service System Requirements The system requirements that are needed are as follows: Agency Management/Parent Organization/Managing Organization Agencies have Sites/Programs and, through them, provide Services. Information about these Agencies, Sites/Programs and Services is made available through ARC Gateway Counselors. Agencies offer Services to the public such as food, housing, financial assistance, care for children and the aging, and substance abuse treatment. Agencies must be associated to specific Sites/Programs, through which Services are offered. Site/Program Management Agencies have publically available Services providing food, housing, financial assistance and many other human services. Agencies can offer one Service or a portfolio of Services that can be offered at one or more Sites [Service locations] or through one or more Programs. Service Management Agencies can offer Services selectively through certain Sites/Programs. As such, there is a relationship between the Agency, the Services offered and the Sites/Programs through which the Agencies have Services available. Referral Searching An I&R Specialist determines the client s need(s) and must be able to referral search the database based on: proximity to individual s location, areas served, and needs. Other resource data fields can be used as referral search filters (ex. Age Requirements, Income Requirements, cost of service). I&R Specialists will then offer the information that meets the client s need(s), based on the results of this search. Third Party Systems Multiple other third party systems are utilized by both users and subscribers. The major systems identified include:

3 Google utilized for information gathering and research Google Maps utilized for address location and geo-spatial reference Simply Get There (ARC) Utilized to identify transportation options Georgia Map to Care Website Utilized to identify licensed facilities Subscribers may have different CLIENT / ELIGIBILITY systems. Website Management / Resource Data Profile Visibility All Agency, Site/Program, and Service information will be added to the resource database- directly or indirectly- by ARC staff; these resources must be immediately visible through a publically available version (website) of the database. However, some resources may not be available directly to the public by accessing this website; Resource Specialist staff must have the ability to designate certain resource profiles as visible to I&R Specialists via referral searching, but not to the public via the website. Resource data profiles must also be able to be designated as visible to I&R Specialists and the public via the website. Finally, resource data profiles must also be able to be designated as visible only to Resource Specialist staff. Data Analysis & Reporting The system must be able to generate resource data reports. All resource data must be available for reporting. Custom reports must be filterable by any data element, including custom fields, as well backend fields, such as Data Provider for resource profiles, AIC for client data, call form submission date/time, resource profile creation or edit date/time, etc. Taxonomy names and codes to which Services are indexed must be a reportable element, selectively includable and filterable as a resource [Service profile] data element. Resource Data Report example: All data fields of all Active Services indexed to a specific taxonomy code, and those Services related Site/Program and Agency names and ID numbers; This reporting function must have the ability to run regularly scheduled reports after hours as well as the ability to execute ad-hoc reports. System should include a number of standard reports consisting of common metrics and also allow for custom reporting of any and all data fields. Access to reporting function will be based on a hierarchical access and managed by administrative staff. Specifically, administrators must have the ability to set permissions. The system must be able to export data at a minimum into Excel. It should have the ability to print into a PDF file. Dashboards The ability to graphically represent real-time snapshot reporting information on an easy to read user interface. Dashboards must be user-editable based on hierarchical access control list. Dashboards must also be able to be limited to information pertaining to one I&R Specialist or one Area Agency on Aging (AAA). Security ARC will be able to control and monitor access for the following software application items: application log in (software access based on login user roles)

4 documents library SQL query access Analytics, reporting, and data. ARC maintains a high level of security on its data. The system must use transport layer security (TSL) or secure sockets layer (SSL) protocols. The system must provide a hierarchical security structure wherein client and resource records are associated with specific users and partners. Users must have profiles with security designations managed by Administrators. This hierarchical security structure must be applied to system functionality access as well as online screens. Application Access ARC has partner agencies and users in multiple locations that are not part of ARC. Thus, the software application must involve a centralized system that will have all resource and client data in a central database and allow access to the central database by both these end users and ARC staff. Software application must support use by ARC and partner agency end users using of a variety of web browsers, including but not limited to Mozilla Firefox, Internet Explorer, and Google Chrome, both the most recent and versions. Abilities to view, submit, and edit call and resource data should be restricted by ARC. Authorized users must be able to edit only resource data for which they are the Data Provider, and only call data that their Specialists submitted, but Administrators must be able to edit all data and must also be able to selectively grant or revoke extended access to other users. Users must be authenticated and all access must be secure Availability System must be available twenty-four (24) hours per day, seven (7) days per week, three hundred and sixty-five (365) days per year, with average downtime- both scheduled and unscheduled- not exceeding one hundred and twenty (120) minutes per month, and periods of intermittent slowness not exceeding ninety (90) minutes per month. Documentation, Training and Support ARC requires thorough user and administrative documentation of the system. Training materials, including user guides for all system functionalities, must be available on the system to all users. Training must be provided for both Administrators and staff end users; trainings must be available for all aspects of system use, and should occur several times during the initial implementation. All trainings must be recorded and available for download in addition to being available for online attendance. System must provide online help for users. Data Conversion System must support resource data conversion (migration) from the legacy application to the new application. Completed resource data conversion will be represented by all resource data profiles existing in the application Integration Capabilities ARC requires the application to provide an open architecture to allow for integration scenarios, such as CTI, API s or other web-based solutions. The architecture of the application must permit these additional

5 services with minimal customization. Some high-priority CTI functions are Webchat, SMS text messaging, and Google Maps and/or GIS mapping. Functional Requirements Data Ability to export any and all resource data Ability to export in CSV, Excel, and PDF Ability to export data, by AAA, and accessible only to authorized password protected users for the assigned area Ability to import data from other partner systems The system functionality should allow a master file of ARC resource data and it should have an API for the file to be automatically loaded. Software should have the ability to have an API to mass load Agencies and Contact data with capacity to extract data from other sources such as Google Maps, Google Docs, and other potential solution providers. Application must have data security practices and standards that ensure that only authorized users can access resource data in fields designated as non-visible to public users. Resource Data Management Ability to selectively designate resources as not included in data reports and other exports Ability to add Sites/Programs to Agencies, and Services to Sites/Programs Ability to add resource information to Agencies, Sites/Programs, and Services, including at a minimum: title; Event; summary/description with limited text; keywords; aliases; service area; main phone number, other phone number, TDD number, fax number, address; website URL with ability to link to website; ADA Accessibility; physical location- full address, and county; mailing address; intake process; documents required for intake; eligibility; income requirements; insurance accepted; fee information; wait list status; other languages spoken; hours of operation. In addition, there should be some fields that are by default visible to I&R Specialists and not to the public (ex. internal notice ). In addition, there should be many fields that are visible only to Resource Specialists (ex. review contact fields, such as name and phone number; record status; last review date; staff note). Ability for an organization to apply for inclusion in the resource database; this should be an easy-to-use form, with automated message prevention, the data from which is delivered to the relevant Network entity or AAA based on the user s provided location. Ability for the Resource Specialist who receives such an application for inclusion through the public website to selectively edit the provided information, and qualify it, thereby adding it in the form of resource record(s) to the database. Ability to link an address field to a map of that location (i.e. Google Map). The map must be included in the Service profile that is visible to I&R Specialists and the public via the website.

6 Ability for Resource Specialists to create web links within certain resource profile data fields (ex. Description, Intake Process), such that by clicking the linked text, Specialists will be redirected (in a new tab or window) to the linked url address. By default, the website field (e.g. Web Address ) on a resource profile should act as a web link, so long as its entry is a url. Ability to assign a status or condition to resource records that determines their visibility to non-resource Specialist staff (ex. Active versus Inactive ). New and duplicate database records should have a unique non-visible status designation by default (ex. New ), requiring a change of status to be visible to non-resource Specialist staff. Ability to designate Services as time-limited, such that they are visible to non-resource Specialist staff only during the time of availability. Advance query builder functionality. Ability to save commonly used queries; query by distance, query services by geography; query services by geo-spatial methods, query services by cost, query by distance Automatic assignment of unique Identification numbers to resource and call records, such that records of either kind can be searched by their unique IDs. Ability to add data quality controls on both the call form and the resource data form. This includes at a minimum: 1) The ability to designate particular fields as always being required for form submission- in the case of a resource record, this would mean requirement for record creation or editing; 2) The ability to designate particular fields as being required for form submission, dependent on the use or input of other fields (ex. Data field A of the call form must have an entry if Data field B had a Yes entry.) Administrators must be able to set and update such form data requirements freely. Ability for administrators to create custom call forms, which can be assigned selectively to data providers. Ability to provide interactive and flexible selection options for service providers. Users must be able to select the top x providers and send to customer. Ability for administrators to add custom call form fields (ex. Is this your first time calling ARC? ). If custom fields do not inherently contain data selection options, then ability to add custom option lists is also required (ex. Yes; No; Not sure ). At a minimum, creation and use of 50 custom fields, and if not part of the field mechanism, 50 custom option lists is required. Public website profile appearance should be customizable by administrators. This customizability includes formatting and field display different from profile views for authenticated users, such as I&R Specialists. Agency and Program/Site profiles should not be viewable by public users/non-authenticated users, although in certain views, their names should be displayed to accompany Service profile names. Software should have the functionality to have multiple Data Providers assigned to multiple programs within the same Agency. Software should have the ability to attach documents to Agency, Program/Site, and Service records (ex. PDF of a flyer advertising a particular Service). The documents should be able to selectively be made visible to non-resource Specialist staff, and must at least be definable as invisible to public users.

7 Taxonomy Services must be able to be indexed to multiple Taxonomy terms, and individual service term indexes on a given service must be able to have one or more target term associations. Services should not be able to be indexed to target terms directly, in the way that they are to service terms. System must include fully viewable taxonomy, including counts of services indexed to each term, and list of services indexed to a term when it is viewed. Ability to index, un-index, and re-index (index to a different term) multiple Services simultaneously, by specified taxonomy term. Functionality must include filters for Data Provider, Agency Name, Service Name, and other factors, at least in terms of which Services are displayed for potential indexing change. Resource Data Maintenance Ability for an already included Agency to submit for review updates about its own Agency, Site/Program, and Service information through the public website. As with new Agency applications, these updates- or notifications of them- must be sent to the relevant Resource Specialist, based on the Agency s Data Provider designation; the Resource Specialist should be able to easily selectively edit the submitted update information and qualify it, thereby causing the record(s) in question to be edited. Provide hierarchical data structure on how Agency, Sites/Programs, and Services relate to each other. Agency hierarchies should be viewable by Resource Specialist staff, such that a record at any of the three levels can easily be opened for editing. On any resource management screen, Agency data provider must be displayed for each Agency. Ability to clone database records. A duplicate record should be generated, require a new name assignment, and then be savable by the user who initiated the duplication. Search capabilities for resource data maintenance to include search filters as: record ID; name; Data Provider; taxonomy/branch indexed; physical address, zip code, city, county; start and end dates; status of record (i.e. active, new, inactive, cancelled). Edits to data fields on an Agency record must be able to be automatically applied, selectively, to corresponding data fields on Site/Program and Service records associated with that Agency. Service records with which they are associated. This type of indirect changing of resource data on lower level records should not be the default. Automatically capture creation and edit dates/times and creator/editor s name on both database data records. Edit logs must be visible to administrators and select staff. Ability to record activities in open text field(s) on database records (e.g. Staff Notes ). Record maintenance activities field(s) should be visible only to staff with relevant access. Ability to prompt Resource Specialist for follow-up with an Agency or Program/Site based on time frames selectable on resource data records. System should have the ability to generate an , automatically and manually, to a recipient whose is stored in a field on a data record, such as an agency data update contact person. This should include data fields which can be custom selected upon manual generation. And a response to the should be sent to the record s Data Provider.

8 System should have the ability to print profiles as part of an update form document that is customizable by authorized Area Information Center staff and includes Data Provider information. By default- set by administrators- certain fields visible to authenticated users should not be printed. However, authenticated users who print profiles should be able to select which fields should be included, with select-all and deselect-all options available. Software should include a search and replace function for Resource Data, whereby criteria can be set to search for all entries pertaining to some specification, in all fields pertaining to some specification, across all resource data profiles, and these entries can be replaced by another specified entry. Software should have the ability to run quality assurance reports on the database, with ability to filter by Data Provider; such reports should allow a user to specify criteria for given resource data fields and be shown which data fields are and are not meeting the specified criteria. This is not simply an export of database fields/records. Referral Search Referral search should include multiple Taxonomy/Use Reference search filters, such that an I&R Specialist can query by multiple terms simultaneously. When multiple terms are searched, results should consist of Services indexed to one or more of the specified terms. Many search filters should be available, and search filter display should be customizable by administrators. Search filters should include but not be limited to: Taxonomy Title/Use Reference; Keyword, which searches profile fields; Agency/Service Name; Area Served; Data Provider; Service ID number; Taxonomy Category, which consists of groups of taxonomies, customizable by administrators; Target Population; Service Physical Location- street name, city, and county. Entries in Area Served resource data record field must respond intelligently to referral search filtering; Resource Specialists can designate zip code(s), city/ies, and/or county/ies that a given Service is available to. When an I&R Specialist or public site user searches for a referral, the input zip code, city, and/or county must be taken into consideration, such that search results consist only of Services that either directly or implicitly include the caller s location in Area Served. I&R Specialist has the ability to specify a zip code, city, and/or county within the Referral Search component that are different from those input on call form to override the call form and referral search outside of Client s area. By default, referral search results must be sorted by proximity to the Client s zip code. Geo Spatial Integration Integration to Google Maps or GIS for location based analysis o Access to transit o Access to health care facilities Services should have demographic fields that accommodate search filtering (ex. age, income, gender) in the same way that other Service data elements such as program, area served, and physical address accommodate search filtering. Ability to track and report on referrals. Services referred should appear on the call form as a result of being selected by an I&R Specialist within the Referral Search component.

9 Reporting Provide and define out-of-the-box or canned reports and views. These should include typical metrics for specified time frames, by geographic area- county, Data Provider area (ex. total calls, with demographic breakdowns; types of needs and totals, with demographic breakdowns; services referred and totals). These reports should be visible within the system (ex. html document), and downloadable in PDF format. The system must have varied standard reports and ability to fully customize reports. Must be able to report on any and all resource data and call form fields, including custom fields. Standard reporting should include robust data graphing options. More complex/custom reports should be exported into.csv or other Excel format. Ability to schedule reports to execute at specified intervals, including afterhours, and with the option to execute on a recurring basis. Ability to manually execute reports at any time. Some reports should include hypertext links (ex. Services referred might link to the Service Profile; presenting need might link to the page that defines that taxonomy term) Miscellaneous Message Board function visible to authenticated users, containing messages from authorized staff at their own organization as well as ARC administrators and other staff authorized to post Network-wide messages. Software Maintenance and Technical Support Selected Respondent must provide qualified personnel to be available to ARC for the reporting of problems/issues with the application. Selected Respondent must include all costs associated with the following services during the initial term and each optional renewal term of the contract. Selected Respondent must provide, at a minimum, the following Services: Basic set up support must be available to ARC immediately upon award of contract. Bi-monthly, conference calls shall be conducted to discuss current support, service issues, and future developments. Help desk support must be available by a telephone number and by Resource data must be easily shared between AAA s, state, regional, and local health and human services agencies Standardized resource reports will be run for use by state and local aging, health, and social service agencies. Provide all source code and database schemas to ARC upon request. Allow and coordinate access to resource data by third party partners upon request from ARC. For example, this may include API support (ex. mobile app developer) to establish a connection with system s data server in order to have a live feed of resource database.

10 Additional Responsibilities Support data maintenance, by adding and updating data fields. Provide ARC with the ability to customize page layout as well as create and modify page layouts for each module. Provide and support a product that allows ARC to develop work flows (notifications and task assignments) and approval rules. Provide and support a product that allows ARC and partner staff to develop and generate customized reports, a product that is equipped with dashboards and views and is available to end users. Provide and support a product that allow "administrator" end-users to create and modify user security as it pertains to form submission, reporting, and data record access, mass data transfer, and other elements. Provide and support a product that has the ability to back-up all data and save to another database if needed for redundancy. Scope of Work ARC wishes to procure software design, development and support services for the development of an information and referral application that integrates seamlessly into existing ARC client tracking system and various third party websites. The following tasks are expected to be conducted. Application Requirements Analysis o Detailed business and user requirements will be developed and documented in this phase. Selected firm will work closely with ARC staff to document specific requirements. Requirements described in this document may change or be removed. An agreed upon requirements document will be developed and presented to ARC management for approval. Application Design o Application design and architecture will be defined based on requirements. Screen mockups and user interface examples will be provided. Data model, user interface, and API layer will be defined in this phase. Design document will be delivered and presented to ARC management for approval. Requirements and design deliverables will serve as guiding documents for development process. Application and Product Development o Successful firm will develop the application based on requirements and design documentation. ARC anticipates an application that can be made commercially available and licensed to other entities. Application Training and Documentation o Application will be fully documented. End user training will also be supplied. It is estimated that approximately 300 users will require training. o Application must be fully documented and shared with ARC Ongoing Support and Maintenance

11 o Upon successful deployment of application, the successful firm will be required to maintain and support the application. ARC may choose to host the application with third party and will ask for optional hosting services. Optional: Application Monthly Hosting Services Respondents are encourage to provide details on application development process and approach. Detailed tasks and estimates must be included along with anticipated time line. ARC envisions a hands on approach to this project and the successful vendor will have substantial interaction with staff and partners. Proposers must include a cost proposal with estimated fees and level of efforts to complete each task. Innovative cost or partnership concepts can be included in proposal. Respondents must provide information about relevant background and skills of company included bios of key personnel and their responsibilities for this project, and examples of similar projects the company has done. Respondents must provide 2 to 3 references. At a minimum, but not limited to, Contractors will be required to adhere to the following: General Financial Requirements and Assurances Assurance of Compliance with Title VI of the Civil Rights Act of 1964 Assurance of Compliance with Section 504 of the Rehabilitation Act of 1973, as Amended, and the Americans with Disabilities Act of 1990 Disclosure of Lobbying Activities Form Certifications Regarding Debarment, Suspension and Other Responsibility Matters; Drug-Free Workplace Requirements and Lobbying Health Insurance Portability and Accountability Act (HIPAA Business Associate Agreement) These forms are not to be submitted as part of the proposal but will be required as a part of the contract documents for successful awardees. It is the policy of ARC that disadvantaged Business Enterprises (DBEs), as prescribed in 49 CFR Part 26, have the maximum opportunity to participate, either as contractors or as subcontractors, in performance of Commission contracts to the extent practical and consistent with the efficient performance of the contract. ARC s current DBE goal is 15.1%. The ARC website provides additional information about DBE. All questions can be addressed to Jennifer Beamer at jbeamer@atlantaregional.com. Questions must be received by December 11 at 5:00 PM and all responses will be posted by 5:00 PM on December 15. Proposals are due by 5:00 PM on December 21, 2015 and can be sent to: Jennifer Beamer Atlanta Regional Commission 40 Courtland Street Atlanta, GA jbeamer@atlantaregional.com t