DOCUMENT
D -- Veterans Binder - TAC-16-24230 (RFI) TAC-16-24230 - Attachment
- Notice Date
- 7/10/2015
- Notice Type
- Attachment
- NAICS
- 541519
— Other Computer Related Services
- Contracting Office
- Department of Veterans Affairs;Technology Acquisition Center;23 Christopher Way;Eatontown NJ 07724
- ZIP Code
- 07724
- Solicitation Number
- VA11815N0467
- Response Due
- 7/16/2015
- Archive Date
- 8/15/2015
- Point of Contact
- Peter Lewandowski
- Small Business Set-Aside
- N/A
- Description
- Background The mission of the Debt Management Center (DMC) is to collect debts resulting from an individual's participation in the Department of Veterans Affairs (VA) benefit programs and VA provided healthcare in the most efficient and cost effective manner while maintaining compassionate, high quality service to Veterans and their families. History To realize this mission, in the early 1970s, the Veterans Benefits Administration (VBA) made the decision to centralize the debt collection process on all benefit debts. In 1974, VBA launched a pilot test collection activity in a centralized environment. This test proved successful and the project went live in January 1975 as the Centralized Accounts Receivable System (CARS). Prior to this, benefits were housed and distributed under different stand-alone systems. The Benefits Delivery Network (BDN) housed the VBA benefit payment systems and stored all debt collection information. VBA paid compensation and pension benefits out of the Compensation and Pension (C&P) system. Loan guaranty debts were also housed in the C&P system for offset purposes. Education benefits, originally referred to as the Government Issued (GI) Bill, were being paid from the Education system under Chapter 34 (Veteran benefits) and Chapter 35 (spouse and dependents' benefits). As a result of the size and complexity of these systems, the new CARS system was written in Common Business-Oriented Language (COBOL) and designed as a stand-alone subsidiary system to BDN. Between 1975 and 1982, various modifications and enhancements were added to CARS but were minor in comparison to the changes that occurred as a result of the Debt Collection Act of 1982. That legislation gave VA significant debt collection tools that authorized interest charging, administrative fees and penalties on delinquent debts. This legislation also authorized the referral of delinquent debts to the Department of Treasury for offset of Federal tax returns and the use of private collection agencies. This authorization drove considerable system enhancements to CARS and the need to design the on-line system called the Centralized Accounts Receivable On-Line System (CAROLS). CAROLS is still used today to view, modify and track collection progress and history on an account. In 1999, DMC began operating as a franchise fund, also known as a working capital fund. Shortly after the move to a franchise fund environment, DMC was moved from VBA to the Office of Management and now reports to the Deputy Assistant Secretary for Finance. Today DMC is responsible for the management of debts incurred from the following benefits programs: education chapters 30, 1607, 1607, 32, 34, 35, and 33; compensation and pension; loan guaranty; and Veterans retraining assistance; as well as other debts that can be offset through withholdings from current compensation and pension payments. In the future, DMC expects to handle debt management for additional VA and Government agencies. Taking on this additional workload is expected to triple its managed portfolio and double its labor force over the next three years. Current Systems Environment Today, DMC relies on a conglomerate of COBOL, Natural, JAVA, JAVNat, and Microsoft code produced over a period of 40 years. Three-hundred to five-hundred programs run daily, and interface with approximately 40 external systems. The current system is an antiquated mainframe-based system that gathers benefits, entitlements, eligibility and payment data from scores of VA, Federal, and other systems that enable their debt collection processes. The users are often required to login to six or more system screens simultaneously in order to complete their role in the debt collection activity. Information is often copied from one screen then pasted into several other screens in order to complete one task. The partial list that follows demonstrates some of the issues created, due to the inefficiencies of the system, such as a significant amount of human intervention: oThe System is inflexible oThe data exchanges between systems are largely done manually and often require code modifications oThe System capabilities are difficult to add to or to modify oThe System requires a large number of workarounds to process debts oThe reconciliation of transactions can take up to three days oThe business processes and supporting technologies are very complex oThe training of a new employee, takes six months to complete; new employees are not highly productive for nearly two years oThe System is not capable of creating new debt types oThe System is not capable of adding new business processes without a major development effort oThe System has no access to pending transactions or historical records oThe System is unable to view notes and retrieve them in a logical order A recent DMC-wide survey produced the following top 10 concerns: Stated Concerns on SurveyCount% 1.Too many systems12179 2.Lack of real-time information10166 3.Redundant entries across systems9662 4.Codes and indicators versus user friendly Language.9260 5.Lack of user tracking/accountability/history8133 6.Missing single sign-on7247 7.Outdated user interface7146 8.Cumbersome systems navigation6643 9.Inflexibility to create notes properly6039 10.Inability to manage correspondence workflow5838 Completed surveys and interviews reflect broad-based concerns across the organization. The concerns range from architectural shortcomings (batch-oriented processing) to complaints about the Graphical User Interface (poorly described fields on green screens). Vision DMC has begun a systems modernization effort with the objective of replacing the current ecosystem of applications. The new ecosystem will continue to include several external systems to support VA-DMC's business activities. From our users' perspective, however, the new system will mask all interfaces with external systems and will provide the user a consolidated view of all business activities related to a Veteran. The following High Level Application Architecture Model shows what we believe to be the future vision of the new System. Veteran Binder The following diagram provides a functional view of the future user interface (Objects in red are not in scope of this Request for Information (RFI)): At the core of the future solution is the Veteran Binder (VB) user interface application. VB is the single source of information about a Veteran. It presents the information from all underlying sources in the ecosystem, including the status of a transaction in progress. The specific information it presents is a function of the user's role. VB is a read only view. The Veterans are also able to view their own binder. Based on their role, the user can select to initiate a business workflow. The execution of the workflow navigates the user to the appropriate underlying application. For example, if the user wishes to change the Veteran's mailing address, the VB User Interface (UI) takes the user to the Case Management system. If the user wishes to send the Veteran a form letter, VB UI takes the user to the Correspondence Management system. A correspondence is the delivery to or the receipt of a document between the Veteran and DMC. A document can be in either a physical or an electronic format. The Correspondence Management (COR) application handles the dispatching and receipt of physical and electronic correspondence. It is the system of record for the Veteran's address. COR supports the definition of predefined document templates populated with workflow specific information. The template definition must allow the user to modify certain sections of the generated correspondence, based on their role. A case is any interaction between DMC and the Veteran. Note that the Veteran can interact with a human agent or by self-service. The Case Management (CAM) application manages each interaction between the Veteran and DMC, by case type. The completion of a case may require correspondence, managed by COR. CAM must allow the definition of case types. A case type defines the script of the interaction with the Veteran and the discrete steps of the case. CAM must publish the status of cases through the service oriented architecture (SOA) at each step. Examples of case types are: "Repayment Plan Requests "Debt Waiver Requests "Disputes "Probate Processing "Bankruptcy The Document Archive (DOC) houses and uniquely identifies all received and transmitted documents across all applications. The key function of DOC is that it is searchable by content, document type and Veteran. It manages the document retention policy. Architecture All workflows report their status through the VB UI. The following diagram depicts the conceptual view of the system architecture (Objects in red are not in scope of the RFI): The ecosystem communicates through an SOA service bus: oOperational Data: This data store contains information about workflows in progress. oData Warehouse: This database contains information about completed workflows. oBusiness Rules Engine: This service provides business rule automation for rules not contained within the individual system. oOrchestration Service: This service manages the workflow state and coordinates activities between applications, using the operational data store and the business rules engine. The operational data store and the data warehouse use a canonical DMC data model. Application can use the data store for application data but will require a data adapter. Similarly, applications can use the business rules engine and the orchestration service. The drawing shows the Accounts Receivable application for information only. The future system will incorporate other applications shown on the baseline CARS/CAROLS drawing above, such as Calabrio or CISCO Unified Intelligence Center, Synergy, etc. We have not depicted these other applications for the sake of simplicity. The following diagram depicts an example of an application needing to send correspondence; form letter xyz. The application initiates a workflow. The Orchestration Service manages the process: Each application performs its function independently but the Orchestration Service coordinates the completion of the workflow. If the vendor proposes a solution that, for example, combines CAM with DOC, the vendor has to show that the various functions are still accessible through the service bus. Outline of Vendor Response The vendor can describe a solution that addresses a single component (VB, COR, CAM or DOC), or any combination of components. The solution must integrate within an SOA by providing appropriate interfaces natively. The solution can be cloud based. The solution must be able to meet (FISMA) High controls: at https://web.nvd.nist.gov/view/800-53/Rev4/impact?impactName=high. It is not necessary to demonstrate compliance in the response. However, the vendor should describe any concerns with compliance. The vendor will provide a five-part response: "Up to 25 pages: oCompany information (Including address, point(s) of contact and their contact information, business size, and any existing contract vehicles that relate to the required services) oTechnical Approach (including deployment approach) oCosting approach or model oCompetitive advantage oPast performances: up to 3, 1 page each oLinks to Supporting Information (Optional) The vendor can supply electronic product documentation, case studies or multimedia that is relevant to the RFI. Requirements The requirements are broken down into the component sections which cover case management, correspondence management, document management, Veteran binder, and shared requirements for all components. For each requirement, the vendor must indicate the level to which their solution meets the requirement: oFully Meets: The solution meets the requirement out of the box. oPartially Meets: The solution does not meet the requirement out of the box but can meet the requirement with configuration. oDoes not Meet: The solution cannot meet the requirement without customization of the software. The vendor can include comments with their response. Again, the vendor can describe a solution that addresses a single component or any combination vendor of components. Case Management Requirements Requirement Area (Type/Feature)Requirement Meet Requirement Search & Identity ValidationThe ability to have a Veteran lookup so that cases can be assigned to Veteran record. (e.g., SSN, file number, name, address, phone number, e-mail address) Case CreationThe ability to automate creation or closure of defined cases based on specified events and/or rules. Case CreationThe ability to define user groups/roles that can manually create defined case types. Document IntegrationThe ability to associate/link scanned documents and/or correspondence for assignment to a new case for when documents arrive in the mail-room. Document IntegrationThe ability to add scanned and electronic documents to open cases for when documents arrive at any point during an open case. WorkflowThe ability to set up queues by case/workflow type in order to manage workflow task aging for supervisory oversight. WorkflowWorkflow capabilities to orchestrate a predefined workflow for each Veteran debt collection case type. WorkflowThe ability to automatically assign and reassign cases to users based on defined rules and roles. WorkflowAllowing privileged users, such as supervisors, to manually assign and reassign cases. Activity ViewA view of Veteran case records opened or closed and all relevant activities performed on cases. GeneralThe ability to add free form text, notes, and comments to all relevant case workflow levels and workflow steps as needed. GeneralThe ability to flag accounts in dispute/review (e.g., DOJ cases) in order to mediate case management activities as needed. Landing PagesThe ability to control views across queues and open Veteran case records within the queues depending on a hierarchy of user roles, groups. Workflow ManagementA means for users to easily identify which Veteran cases are assigned to themselves and which state each record is at in order to facilitate prioritization. Workflow ManagementThe ability to calculate duration or each case and workflow step within a case from time opened until closed. Workflow ManagementA summary dashboard view of open cases for management and quality review. Workflow ManagementThe ability to establish time unique time thresholds for case types and workflow steps. Workflow ManagementA means to for an escalation alert on cases and workflow steps nearing/exceeding time thresholds. Workflow AdministrationA user interface for assigned user roles to create and administer case types and workflows steps. Document IntegrationThe ability to view, link and retrieve document content from external document management systems associate and associate these with case records within the case management solution. Correspondence Management Requirements Requirement Area (Type/Feature)Requirement Meets Requirement Correspondence AddressThe ability to maintain multiple addresses for a Veteran for the purpose of sending correspondence. Correspondence AddressThe ability to maintain a default addresses for a Veteran, but also allow for manually overriding. Correspondence AddressThe ability to allow for address synchronization through an interface with the system-of-record (SOR) Incoming Correspondence The ability for incoming physical mail correspondence to be scanned by a document management system. Case Management InterfaceThe ability to be integrated with case management for the purpose of sending and tracking correspondence related to case management process. Bulk Outgoing MailingsThe ability to enable bulk mailings to a filtered set of Veterans on a based on business rules or on an ad hoc basis. Mail MergeMail merge capabilities for address and other variables fields in order to individualize templates. External FulfillmentThe ability to implement an interface with external fulfillment partners such as World Marketing Inc., as needed, to facilitate correspondence. Bad Address TrackingThe ability to process and track undeliverable/returned mail for follow-up activity. Template listingThe ability to display a list of VA approved letters. Template ManagementThe ability to create, load, edit, and delete templates for electronic and paper correspondence for privileged users. Template ManagementThe ability for letter versioning and role-based approval processes before being enabled for active use. Record Retention and HistoryThe ability to maintain and display a history by Veteran of letters/bills and attachments sent that indicates which correspondence was sent, the date it was mailed, the address to which it was sent, the program or user that requested it, and whether the letter/bill was returned as undeliverable. Record Retention and History The ability to maintain copies of version-controlled system letters, etc., in a way that allows users to produce a copy of the item as it looked on a specific date OR an imaged copy of the actual item sent. Correspondence AddressThe ability to maintain multiple addresses for a Veteran. Correspondence AddressThe ability to maintain a default address for a Veteran, but also allows for manually overriding. Correspondence AddressThe ability to store a history of incoming email related to a Veteran record. Outgoing Electronic The ability to send secured outgoing response e-mail(s) to a Veteran as required. Outgoing ElectronicThe ability, to the extent practical, use approved standard paragraphs when composing custom responses to inquiries. Outgoing Electronic TrackingThe ability to track returned emails, bad emails addresses, read receipts for emails sent. Document Management Requirements Requirement Area (Type/Feature)Requirement Meets Requirement Document lifecycleThe ability to manage documents across the lifecycle from scan to document retention ClassificationThe ability to create a document classification scheme MetadataThe ability to add rich metadata to documents MetadataThe ability to define standard metadata by document type. Role SecurityThe ability to control document upload, view, edits, and deletion by role. InteroperabilitySupport Content Management Interoperability Services (CMIS) so that documents can be integrated as content within other systems such as case management. Veteran Binder Requirements Requirement Area (Type/Feature)Requirement Meets Requirement Correspondence AddressThe ability to integrate content from multiple systems to create an integrated view of the Veteran. Correspondence AddressThe ability to create default views and landing pages by user roles. Integration The ability to operate in a SOA for the purpose of displaying real-time data from disparate systems. Information security The ability to securely restrict content at the level of certain users and/or user groups to certain Veterans. Shared Requirements for all Components Requirement Area (Type/Feature)Requirement Meets Requirement SSOThe ability leverage single sign-on with Active Directory. Information Security The ability to be Federal Information Processing Standard 140-2 Compliant. SecurityThe ability to meet FISMA high controls. Audit TrailThe ability to log all user activity. AccessibilityThe ability to comply with Section 508 of the Rehabilitation Act.
- Web Link
-
FBO.gov Permalink
(https://www.fbo.gov/notices/7b54b89ffe89570e00caf78a8176be0a)
- Document(s)
- Attachment
- File Name: VA118-15-N-0467 VA118-15-N-0467.docx (https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=2159971&FileName=VA118-15-N-0467-000.docx)
- Link: https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=2159971&FileName=VA118-15-N-0467-000.docx
- Note: If links are broken, refer to Point of Contact above or contact the FBO Help Desk at 877-472-3779.
- File Name: VA118-15-N-0467 VA118-15-N-0467.docx (https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=2159971&FileName=VA118-15-N-0467-000.docx)
- Record
- SN03792710-W 20150712/150710234738-7b54b89ffe89570e00caf78a8176be0a (fbodaily.com)
- Source
-
FedBizOpps Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |