Loren Data's SAM Daily™

fbodaily.com
Home Today's SAM Search Archives Numbered Notes CBD Archives Subscribe
FBO DAILY ISSUE OF JANUARY 10, 2013 FBO #4065
SOURCES SOUGHT

D -- Electronic Case Processing

Notice Date
1/8/2013
 
Notice Type
Sources Sought
 
NAICS
541512 — Computer Systems Design Services
 
Contracting Office
Department of Health and Human Services, Program Support Center, Division of Acquisition Management, 12501 Ardennes Avenue, Suite 400, Rockville, Maryland, 20857, United States
 
ZIP Code
20857
 
Solicitation Number
PSC0002
 
Archive Date
2/9/2013
 
Point of Contact
Michael T. Fischer, Phone: 3014430728
 
E-Mail Address
Michael.Fischer@psc.hhs.gov
(Michael.Fischer@psc.hhs.gov)
 
Small Business Set-Aside
N/A
 
Description
Electronic Case Processing Environment OMHA Small-Business Sources Sought This is a Small Business Sources Sought notice. This is NOT a solicitation for proposals, proposal abstracts, or quotations. The purpose of this notice is ONLY to invite qualified socio-economic firms to submit capability statements demonstrating the ability to provide the services listed below. To be included in the capability statement, firms shall include information regarding: (1) the availability and capability of qualified small business sources; (2) whether they are small businesses; HUB Zone small businesses; service-disabled, veteran-owned small businesses; 8(a) small businesses; veteran-owned small businesses; woman-owned small businesses; or small disadvantaged businesses; and (3) their size classification relative to the North American Industry Classification System (NAICS) code for the proposed acquisition. Your responses to the information requested will assist the Government in determining the appropriate acquisition method, including whether a set-aside is possible. An organization that is not considered a small business under the applicable NAICS code should not submit a response to this notice. Background: Under the Department of Health and Human Services(HHS), the Office of Medicare Hearings and Appeals (OMHA) was created to accommodate the increased surge of appeal activity resulting from the Medicare Modernization Act of 2003, Specifically OMHA is charged with streamlining efficiencies through electronic appeal processes.. OMHA's Administrative Law Judges hold hearings and issue decisions related to Medicare coverage determinations that reach Level 3 of the Medicare claims appeal process. OMHA began processing appeals in 2005. In the last year, the OMHA workload has more than doubled. In FY12, OMHA processed about 375,000 appeals and claims. In addition to the headquarters in Arlington, VA, there are four field offices (Irvine CA, Cleveland OH, Arlington VA and Miami FL.) In total, OMHA has about 475 employees. There are five levels in the Medicare appeals process: • Level 1 - Redetermination - Examination of a claim by person different than the person who decided the initial claim. Administered by the 15-20 Medicare Administrative Contractors (MAC.) • Level 2 - Reconsideration - An independent review of medical necessity issues. Administered by the 3 Qualified Independent Contractors (QIC.) • Level 3 - Administrative Law Judge (ALJ) hearing. Administered by OMHA for whom the system discussed in this notice is intended. OMHA has approximately 475 employees. • Level 4 - Appeals Council review. Administered by the Departmental Appeals Board (DAB.) Currently, the DAB has less than 100 employees. • Level 5 - United States District Court The following is a high level summary of OMHA's workflow: As a case moves through the appeals levels, the appellant submits copies of medical records and other evidence to justify the claim. The level 1 and 2 Medicare Contractors scan in these documents and primarily work the cases in an electronic format. OMHA, however, works in a paper environment. Below is a high level summary of how the process currently works at OMHA: 1. The Medicare appellants submit a paper request for hearing and supporting documentation to OMHA. 2. Upon receiving the request at the Central Operations Division in Cleveland, OH, they assign and forward the request to a field office team and fax a request for the case file to Level 2. 3. Level 2 prints out a copy of the electronic case file and ships it to the field office that the case was assigned to. 4. Upon receipt of the case file, OMHA field office case intake pulls the paper request for hearing out of storage and delivers both files to the Judge's team Legal Assistant. 5. The Legal Assistant organizes the file into sections and tabs each section in a process called exhibiting. The Legal Assistant then places the exhibited file in storage awaiting review. 6. The Attorney reviews the case file making notes for the Judge. 7. If a hearing is required, the Legal Assistant manually schedules the hearing and creates a Notice of Hearing and mails it to all applicable parties. 8. The Judge holds the hearing using the paper case file and makes an audio recording of the proceedings. 9. The Judge writes decision instructions for the Attorney. 10. The Attorney drafts the decision and gives it to the Judge for review and signature. 11. The signed decision is given to the Legal Assistant who mails copies to the parties. 12. The Legal Assistant ships the audio CD of the hearing, a copy of the decision and the case file to the Administrative Qualified Independent Contractor (AdQIC). 13. The AdQIC effectuates the decision and ships the case file to a storage location. 14. If the case is appealed to Level 4, the AdQIC ships the case file to the DAB. Currently, OMHA uses a paper process to manage workload and uses the Medicare Appeals System (MAS) data repository. MAS consists of a Siebel user interface, Oracle database, IBM Content Manager, Kofax document capture and Cognos Analysis and Reporting. MAS is currently operated by the HHS's, Centers for Medicare and Medicaid Services (CMS) and is physically located at the CMS Baltimore data center. MAS is the core database repository that all of the Levels of the Medicare appeals process interface with: Level 1 - The MACs use their own systems and send data to MAS at the completion of the case to document their decision. Level 2 - The 3 QIC contractors use their own systems for processing and also enter data into MAS at the beginning and end of the case for case control. They work electronically but currently print the case folder to send to OMHA. Level 3 - OMHA works primarily on paper entering data into MAS for case control. Because of MAS limitations, user developed ad hoc systems are used to supplement MAS. Level 4 - The DAB has their own case control system (the Automated Case Tracking System) and has little interaction with MAS. In an effort to accommodate the rapidly growing workloads, OMHA needs to take advantage of the efficiencies that electronic processing can produce. To accomplish this, socio-economic firms are invited to provide capability statements that demonstrate technological experience and qualifications regarding the electronic infrastructure necessary to meet the needs of OMHA's vision. This includes the ability to interface with the various field offices mentioned above. The new system will be called the Electronic Case Processing Environment (ECPE). Purpose and Objectives: OMHA seeks information on available commercial off the shelf products/solutions and ancillary services for implementation and support of the Electronic Case Processing Environment (ECPE) to substantially improve the delivery and efficiency of appeals processing services. The foundation of the ECPE is to be a web-based and highly configurable dynamic case management application that will provide: • Dynamic workflow, configurable largely without coding, including task based user interfaces and task and workload tracking/management. • Data management including extensive rules-based calculations, data validation, process initiation, and action/deadline alerts. • Electronic document management including document capture, automatic classification/categorization and indexing of structured and unstructured documents, extensive document/file structuring/restructuring, document storage, and document deletion. • Electronic document manipulation and presentation (exhibiting) including splitting, excerpting, duplicate identification, page reordering, search capabilities, permanent stamping, locking, multiple factor indexing, annotating, bookmarking and highlighting. • Correspondence generation, which involves merging data with template-based and ad-hoc content; and decision generation, which also involves dynamic logic-based construction of decisions from both stored and ad-hoc content. • Seamless interfaces with the Medicare Appeals System including its component/supporting systems (Oracle database, IBM Content Manager, Kofax document capture) as well as a number of feeder systems providing data regarding claims, providers, beneficiaries, etc. • Role-based profiles regarding external parties and participants to the appeal such as appellants, providers, beneficiaries, medical experts, MACs, QICs, etc. These profiles will be essential to rules-based determinations regarding receipt of notifications, decisions, specific data to be included within notifications and decisions, etc. • Scheduling of hearings, resources, and internal (e.g. ALJs) and external participants. • Secure web-based electronic filing and access to appeal status information and case documents. • Robust reporting, business intelligence, and analytics. • Processing and storage (data, documents, etc.) of 60,000 - 120,000 records/appeals at implementation. Project Requirements: ECPE will need to support a number of critical OMHA functions and requirements, including, but not limited to: 1. General Requirements Development : Building upon OMHA developed requirements; the vendor employs an Agile systems design and development process to ensure that the final product meets the users' needs. The vendor will be responsible for the development of detailed systems specifications. A flexible platform that can be configured to meet OMHA's business needs. OMHA should have the ability to administer much of the configuration. 2. Receive Case : ECPE must create a new record for all incoming cases including those that are presently processed as paper cases and those submitted online in ECPE. Data will be propagated to the newly created record from other systems, but the case creation module must permit additional data to be entered manually. ECPE must include an automated/preliminary screening process designed to reduce or eliminate unresolved issues prior to starting case processing. 3. Interface with Database Repositories : ECPE must interface with the MAS Oracle database where the case data is stored and potentially with other CMS databases such as the national provider database, beneficiary database, Medicare claims database, and the IBM Content Manager system where unstructured and semi-structured data is stored. (Some, but not necessarily all interfaces will be implemented via IBM WebSphere.) OMHA would use the vendor's document/content management system and database for day-to-day work. Data would be pulled from the CMS databases at the beginning of a case and sent back down (for access by other levels) at the close of a case. This should allow access to the electronic case file and seamless data sharing between Medicare Levels 1-4. 4. Promote Case : ECPE must include a process for promoting (importing) Level 2 case data held in other systems to a Level 3 case created in ECPE. It must allow the Docket Clerk to verify that all required information is present in the newly created appeal and allow updates where necessary. 5. Assign Case : ECPE must permit the assignment of cases based on weighted factors to workers, either manually or automatically, by using case data, profile information, ALJ availability, and local business rules. A maintenance function must exist that allows authorized users to internally transfer/redistribute workloads among employees and among components at any time (single cases or groups of cases). 6. Analyze Case : ECPE must include business rules support and logical lines of questioning (intelligent pathing) to guide the user through the decision making process. ECPE must accommodate variations in the evaluation process based on defined rules. Information gathered during case analysis must be captured and be available for propagation into a rationale. 7. Manage Documents : ECPE must be the means for adding, deleting and retrieving electronic documents including evidence, notices, prior level documentation, and digital recording of the hearings and decisions. a. Classify Documents : ECPE must be able to automatically classify/categorize and index structured and unstructured documents. b. Manipulate Documents : ECPE must be able to support complex document manipulations such as splitting, excerpting, duplicate identification, page reordering, search capabilities, permanent stamping, locking, multiple factor indexing, annotating, bookmarking and highlighting. These functions must be accomplished via user-friendly techniques such as cut and paste, drag and drop, thumbnail views and thumbnail manipulations. ECPE must provide auditing and versioning capabilities for all document manipulations. 8. Perform Exhibiting : Using the functionality in Manage Documents, Classify Docments, and Manipulate Documents ECPE must enable the worker to perform exhibiting of the case file. Exhibiting organizes case file documents into categories. The exhibit content is structured and grouped by File/Exhibit category. 9. Send Communication : Communications may be automatically or manually initiated. Communication methods must typically be determined based on the contact's profile. Communication methods that have been identified are: centralized printing and mailing, local printing and mailing, automated faxing, automated phone calls, emails, text messaging, and XML. Batching of outgoing communication must be supported so that all messages to a particular recipient are received together. The system must have controls on the release of sensitive information and must conform to OMHA's security and PII requirements. 10. Generate Correspondence : ECPE must automatically generate correspondence upon completion of defined tasks. It must bulk-generate documents at defined time periods. For example, it must notify hearing participants of the hearing by generating a Notice of Hearing sent via mail, email or calendar invites. 11. Receive Communication : ECPE must associate incoming evidence with the appropriate cases, including cases that are no longer active, and must then update the case records to display the receipt of evidence and alert the appropriate workers of receipt. Evidence and other communications may be received directly from experts, claimants, third parties, and appointed representatives via website, secure website update (email), fax, electronic file transmission, telephone, postal mail, and text messages. Video recordings of appellant interviews must also be received as evidence. 12. Initiate and Approve Pre-hearing Request : ECPE must enable a worker to request or modify a pre-hearing and must provide for ALJ review and approval of the request when necessary. The need for review and approval must be identified based on the user profile or business rules. a. Schedule Hearing : ECPE must provide the ability to schedule, modify, or cancel hearings and any special arrangements manually or automatically based on defined business rules. 13. Perform Task Request : ECPE must enable the user to initiate, fulfill, follow-up on, or cancel a request for assistance from other workers throughout case development. Task requests must typically be associated with a case, but may be independent of a case. a. Make Decision : ECPE must support the recording of the final decision and the rationale for the decision. b. Electronic Signatures : ECPE must be able to electronically sign documents using HSPD-12 compliant authentication and security. c.Send Decision Notification: ECPE must gather all information that must be included in the decision notification and send electronic communications to the appropriate downstream systems. 14. Perform Internal Quality Review : ECPE must select cases for in-line or end-of-line quality review based on pre-defined sampling criteria and case maturity points that are subject to ad hoc modification. ECPE must also allow cases to be selected manually for review. When a case meets set criteria for review, appropriate staff must be alerted based on business rules. 15. Administer Application Settings : ECPE must provide national, regional, and local ability to make adjustments to pre-defined settings (also known as business rules) that may be modified by an authorized employee under certain circumstances. These settings must determine how cases are assigned, routed, and selected for internal quality review, as well as define timeframes for specific case actions. 16. Administer User Profiles : ECPE must provide the ability to establish, define, and fine-tune user roles and authorities at the site, region, or national level. ECPE must allow some users to be assigned multiple roles. 17. Case Auditing : ECPE must validate the completeness and integrity of the case and must notify and create tasks if problems are found. 18. Case Tracking : ECPE must provide the ability for internal users to view case status and customize workload management using an interactive "dashboard" interface. The dashboard interface must be customizable at the user level and must highlight all cases, task requests, and other workloads for which the user is responsible based on user preferences and must also provide filtering and sorting capabilities. 19. Secure Web Portal : ECPE must provide the ability for authenticated external users, such as appellants and authorized third parties to file an appeal and access specific case information through a secure web access portal. The secure web portal should accommodate on-line completion, signing, and submission of Medicare related forms. ECPE must be able to accept certified electronic signatures on the forms. This service shall provide user verification compliant with Federal e-authentication level 3. 20. Security Requirements - The system must meet all Federal security regulations as defined by Federal Information Processing Standards (FIPS) and Federal Information Security Management Act (FISMA). The system shall support single sign-on integration with the HHS active directory and sshall be able to support Personal Identification Verification (PIV) card integration. 21. Administer Management Information (MI) and Workload Management : ECPE must include administration of standard, ad hoc, automated and custom reports for internal and external use and ECPE must capture real-time metrics on all case attributes, tasks and processing ages at both detailed and summary levels for workload management purposes. ECPE must capture and provide cross-component MI and use consistent MI methodologies across components (including the hierarchy of MI with drill down and roll up capabilities). ECPE must provide a single point of access for all MI. 22. Manage Appellant, Third Party, and Expert Information : ECPE must include the ability to receive and manage account profile information for all contacts, including appellants, third parties, and experts and must retain a history of changes. This function must include a hierarchy of contact preferences, such as the optimal times to be contacted, preferred methods of contact, accessibility needs, and follow-up timeframes. 23. Implementation support : The vendor must be able to provide onsite support at all OMHA locations during implementation and possibly at other times or throughout the system lifecycle. a. Training : The vendor must provide training support to train the systems administrators and users. b. Help Desk : The vendor must provide help desk support to answer questions and resolve problems. c. Hosting : ECPE must be able to be hosted in the vendor's or a third-party environment, for which systems, infrastructure, and facilities are FedRAMP or FISMA certified at the moderate risk level (FedRAMP/FISMA certification is a vendor responsibility). Anticipated period of performance N/A Disclaimer and Important Notes. This notice does not obligate the Government to award a contract or otherwise pay for the information provided in response. The Government reserves the right to use information provided by respondents for any purpose deemed necessary and legally appropriate. Any organization responding to this notice should ensure that its response is complete and sufficiently detailed to allow the Government to determine the organization's qualifications to perform the work. Respondents are advised that the Government is under no obligation to acknowledge receipt of the information received or provide feedback to respondents with respect to any information submitted. After a review of the responses received, a pre-solicitation synopsis and solicitation may be published in Federal Business Opportunities. However, responses to this notice will not be considered adequate responses to a solicitation. Confidentiality. No proprietary, classified, confidential, or sensitive information should be included in your response. The Government reserves the right to use any non-proprietary technical information in any resultant solicitation(s). Interested small business firms are highly encouraged to respond to this notice. However, firms should understand that generic capability statements are not sufficient for effective evaluation of their capacity and capability to perform the work required. Responses must directly demonstrate the company's capability, experience, and ability to marshal resources to effectively and efficiently perform the objectives described above. Capability statement: Interested socio-economic firms are invited to submit a capability statement on their company's ability to perform. Specifically, firms must thoroughly address the firms capability in providing all 23 performance tasks identified under Project Requirements above. Additionally, the capability statement must include: : • Information about their organizations: (a) staff expertise, including their availability, experience, and formal and other training; (b) current in-house capability and capacity to perform the work; (c) prior completed projects of similar nature; (d) corporate experience and management capability; and (e) examples of prior completed Government contracts; (e) references, and other related information; • OEMs/software publishers: Indicate if your product(s) may be expected to address the full scope of capabilities with configuration and/or minimal customization. If not, explain your experience and relationships with other COTS products that may need to be integrated in order to address the full scope of capabilities. • Integrators: Explain your experience and relationship with OEMs/software publishers that you might propose to meet the core capabilities. If the core product may require integration with other COTS products, explain your experience and relationship with such other COTS products. • All respondents: Explain your hosting capabilities or your experience and relationship with another hosting provider. • respondents' DUNS number, organization name, address, point of contact, and size and type of business (e.g., 8(a), HUB Zone, etc.) pursuant to the applicable NAICS code; • technical and administrative points of contact, including names, titles, addresses, telephone and fax numbers, and e-mail addresses • Federal Supply Schedule information (if applicable) Responses shall be delivered, via email, in Microsoft Word format and must be received by 4PM EST January 25, 2013 Page limitation of responses: Fifteen (15) Responses shall be addressed to: Michael T. Fischer Contract Specialist Program Support Center Department of Health and Human Services Office: (301) 443-0728 Email: Michael.Fischer@psc.hhs.gov
 
Web Link
FBO.gov Permalink
(https://www.fbo.gov/spg/HHS/PSC/DAM/PSC0002/listing.html)
 
Place of Performance
Address: Various locations across the Continental U.S., United States
 
Record
SN02961469-W 20130110/130108234652-2b27b7d7f01b000a4a4f088fcd39a484 (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 |
ECGrid: EDI VAN Interconnect ECGridOS: EDI Web Services Interconnect API Government Data Publications CBDDisk Subscribers
 Privacy Policy  Jenny in Wanderland!  © 1994-2024, Loren Data Corp.