SOURCES SOUGHT
70 -- Electronic Forms Submission and Processing System
- Notice Date
- 8/16/2005
- Notice Type
- Sources Sought
- NAICS
- 511210
— Software Publishers
- Contracting Office
- Social Security Administration, Deputy Commissioner for Finance, Assessment and Management, Office of Acquisition and Grants, G-C-7 East High Rise Building 6401 Security Blvd., Baltimore, MD, 21235
- ZIP Code
- 21235
- Solicitation Number
- SSA-RFI-05-1009
- Response Due
- 9/6/2005
- Archive Date
- 9/21/2005
- Description
- The Social Security Administration (SSA) seeks to identify and evaluate vendors that are capable of providing for a Development and Implementation of a National Electronic Forms Submission and Processing System. Necessary information to be received from vendors requires a clear and definitive description of the vendor?s product and software support capabilities as well as the requirements that are needed to successfully operate the system within the Social Security Administration (SSA) environment. SSA is an independent agency whose objective is to provide retirement and disability services. The agency is comprised of the headquarters and field offices. Inclusively, there are 65,000 employees with an additional 14,000 employees in the 54 Disability Determination Services (DDS) offices, and one federal DDS, each having its own infrastructure. Commissioner Jo Anne B. Barnhart leads the agency in its mission to enhance the lives of Americans through its leadership of Social Security programs. The Office of Disability and Supplemental Security Income Systems (ODSSIS) is responsible for the software development life cycle (SDLC) of SSA?s eForms system. The eForms system provides an automated method for the disability determination claims and approval process. SSA estimates that the number of nationwide eForms users is approximately 79,000 including users in the DDS offices. Currently, SSA maintains 2,870 active forms, 673 of which have been printed within the last four years on a regular basis. Within eForms, SSA has developed over 250 electronic forms using JetForm FormFlow Classic 2.2. There are also seventy-nine electronic forms which have been developed using Adobe Form Designer 5.0. The forms created in Adobe Form Designer 5.0 are accessed via the SSA intranet through a customized electronic forms product known as ?FormSelector?. FormSelector allows users to access eForms and provides a toolbar offering a common user interface for all forms. In addition, several legacy applications interface with FormSelector. FormSelector?s custom Application Programming Interface (API) is used to invoke an eForm within an application. These applications are based on either web or client/server technologies. They have been written in technologies such as WebSphere, Visual Basic .NET, and Visual Basic 6. In addition to invoking eForms, these applications are also able to pre-populate fields with data. SSA plans to migrate to a system that provides a solution that is primarily web-based. The software must provide SSA with a reliable, scalable architecture that permits users to access the system via the Internet or the SSA intranet. In addition, the solution should provide the ability to leverage current SSA technologies and be capable of adding functionality using standard development tools (e.g. HTML, Java, and JavaScript). Correspondingly, SSA seeks a solution that enables a standard method of integrating the form solution with the existing legacy systems. Accessibility Considerations of the Software: Any software used at SSA must be compatible with Federal Government Section 508 Standards. Information concerning Section 508 standards can be found at www.section508.gov. The software would need to be able to meet the following sections of Section 508 compliance: Section 1194.21 ? Software Applications and Operating Systems; Section 1194.22 ? Web-based Internet Information and Applications; Section 1194.31 ? Functional Performance; and Section 1194.41 ? Information, Documentation, and Support. The Social Security Administration uses the JAWS (speech input/audio output) and MAGic (screen magnification) products from Freedom Scientific Corporation, as well as Dragon software for mobility impaired individuals. All software must support these products. Section 508 Compliancy: Interested vendors must be able to demonstrate in sufficient detail their ability to meet the Agency?s requirements (e.g., experience utilizing standards based technology and enterprise-wide web-based solutions). Vendors should provide the names and contact information of customers. We reserve the right to verify information with references. Vendors must be able to provide the following: reliable customer support, thorough documentation, and knowledgeable staff. Vendors must be financially stable and firmly established. Vendors submitting responses should indicate whether their products are available on the GSA schedule. Vendors are requested to provide responses that describe how the product will accommodate SSA?s system needs as follows: (1) Product Offering- Describe how the software fully encompasses the eForms solution. (2) System Architecture-Describe the major design principles/elements of a potential technical architecture for an eForms system; and Address interfaces/interface processes to other applications and databases. (3) eForms Conversion Process-Explain the conversion method and processes required to convert existing SSA eForms. (4) Specific Requirements-Provide detailed descriptions of how the software meets the specific requirements for each of the following items: (1) eforms: (a) Ability to manage the development of and modifications to eForms templates; (b) Allow for customization without significant programming; and (c) Add new functionality via widely used technology (e.g. Java, JavaScript). (2) Richer User Experience: (a) Navigation: Easily navigate to dynamically fill able fields, to other forms, and across other applications; (b) eForm Retrieval: Selection of form templates with quick and convenient access from disparate sources; (c) Enhanced features (e.g., Search feature, Spell-check, Toolbar actions, and Customizable dialog boxes); (d) Monitoring and Reporting: Allow for both ad-hoc and predefined reports that can be viewed, printed, and exported to other applications, as a method of providing metrics; (e) Integration: Seamless integration with other tools (e.g. Microsoft Word, Outlook, Excel); and (f) Printing: High resolution print quality. (3) Standardized Interface-Ability to interface with multiple commonly used platforms and applications. (4) Saving eForms- (a) Save an eForm to a specified location as a self-contained format supported by applications across multiple platforms; and (b) Save an eForm in a secure, protected format. (5) Document Repository-Provide compatibility with a document repository that allows for the submission of eForms. (6) Data Propagation-Ability to handle pre-population of fields within a form by accessing other data sources, using standards-based Application Programming Interface (API) (e.g., HTTP, SOAP, XML, web services). (7) Digital Signatures-(a) Digitally sign an eForm using standards-based authentication technology; and (b) Ensure non-repudiation of a digital signature. (8) Processing- (a) Performance: Retrieve an eForm through an API call, open an eForm, enter data, and perform save functions in a timely manner; (b) Pre-process rendering (e.g., conversion of an eForm to HTML when needed); and (c) Status Tracking to monitor the status of an eForm during the workflow cycle. (9) Flexible Storage Facility-Ability to store, manage, and retrieve eForm data and metadata for future reference. (10) Security- (a) Provide robust security for data, both from within the form as well as from system to system; (b) Authentication to other applications with limited or no user intervention (i.e., user is not prompted to enter a user ID and password when submitting documents); (c) Restrict access to users based on the status of an eForm; (d) Provide authorization based on user roles; and (e) Ensure the inability for modifications to a digital signature. (11) Deployment-Ability to deploy patches in a reliable manner, without resulting difficulties, compatible with standard tools (such as Microsoft Systems Management Server (SMS), and Novadigm Radia) with limited client-side components and seamless updates without user intervention. (12) Section 508 Compliance-Ability to meet Section 508 standards and to permit enhancements to improve the product?s accessibility. Format of Response: This is a request for information only, and is not intended as a request for proposal. The Government does not intend to reimburse for any information or materials submitted in response. Respondents will not be notified of the results of the evaluation. No contract award will be made on the basis of the responses received. Responses should be submitted, within 15 business days of the publication of this notice, to the Social Security Administration on or before 5:00 P.M. EDT Date. Electronic responses are preferred and can be sent to: Kevin.Muniz@SSA.gov in the Office of Acquisition and Grants. Please include eForms RFI Responses in the subject line. SSA will also accept non-electronic responses. Paper responses should be mailed to: Social Security Administration, Office of Acquisition and Grants, Attention: eForms RFI Responses, 7111 Blvd. Place Building, Suite 100, Baltimore, MD 21207. Responses should refer to RFI Number: SSA-RFI-05-1009.
- Place of Performance
- Address: 6401 Security Blvd., Baltimore, MD.
- Zip Code: 21235-2000
- Country: USA
- Zip Code: 21235-2000
- Record
- SN00872041-W 20050818/050816213117 (fbodaily.com)
- Source
-
FedBizOpps.gov Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |