Attachment 1 CSTAR IDIQ SOW.doc

Attachment 1

Office of Information Management (OIM) &

Center for Devices and Radiological Health (CDRH)

Center Submission Tracking and Reporting (CSTAR) Indefinite Delivery/Indefinite Quantity (IDIQ) Statement of Work (SOW)

1. Introduction 1.1 Background The Food and Drug Administration (FDA) is the federal agency responsible for protecting the public health by assuring the safety, efficacy, and security of human and veterinary drugs, biological products, medical devices, our nation’s food supply, cosmetics, and products that emit radiation. The FDA is also responsible for: advancing the public’s health by helping to speed innovations that make medicines and foods more effective, safer, and more affordable; helping the public acquire the accurate, science-based information they need to use medicines and foods to improve their health.

The work and business of FDA’s Center for Devices and Radiological Health (CDRH) is extremely information intensive. As such, the Center continues to increase its reliance on the successful operation, maintenance, and enhancement of its information technology systems, which enable FDA to meet the following statutory requirements:

· FDA Modernization Act of 1997

· Clinical Laboratory Improvement Amendments of 1988

· Medical Device User Fees and Modernization Act of 2002

· FDA Amendments Act of 2007 Note: For additional background information on FDA/CDRH, please visit our website: http://www.fda.gov/MedicalDevices/default.htm Two systems that are critical to meeting these regulatory requirements are the Center Tracking System (CTS) and CDRH Ad-Hoc Reporting System (CARS). Collectively, these two systems represent the current Center Submission Tracking and Reporting (CSTAR) suite of applications. These applications are in a mixed life-cycle mode, with both traditional operations and maintenance and enhancements occurring in parallel.

1.2 CTS Overview

The CDRH Center Tracking System (CTS) is a web-based, custom-coded workload management and tracking system. It tracks assignments and workflow steps associated with regulatory reviews, inter-office consultations for facilitating the exchange of scientific information and staff expertise, and task completion dates and other key indicators required for performance scorecard reporting.

CTS is used by every office within CDRH. A typical workday involves 300 unique accounts logging in per day, with a load of 150 users at any given point. It handles over 20,000 workflow operations per month for thousands of users and coordinates over 15,000 inter-office consult requests per year.

Originally, CTS was introduced to CDRH in February 2004. At first, it was developed to track the progress of premarket documents through the review process. CTS also was designed to read/write data from a legacy database that contains premarket documents entering CDRH through the Program Operations Staff (POS) Document Control Center (DCC). These entries are primarily paper submissions, but CTS tracks submissions received electronically as well.

Although users see CTS as a single system, it is divided into the subsystems, or modules, listed in Appendix A. Subsystems may be logically separate, but modules share much of the same code when functionality is similar. Appendix B lists the development tools and technologies behind CTS.

Additionally, CTS interfaces with other FDA systems, including the CDRH electronic document repository (Image 2000), CDRH data warehouse (CARS), RadHealth electronic submission system (RH Pro), and FDA’s Office of Regulatory Affairs (ORA) Field Accomplishments and Compliance Tracking System (FACTS), FDA Uniform Registration and Listing System (FURLS) and Recall Enterprise System (RES). CTS reads and updates data in the CDRH transactional database, which stores pre- and post-market information from industry submissions, adverse event reports, and other sources.

1.3 CARS Overview

The CDRH Ad-Hoc Reporting System (CARS) is a data warehouse with daily updates from CDRH databases. It is a database geared towards the business intelligence and reporting requirements across the Center. The data warehouse integrates with data from the various operational systems and loads data from these systems at regular intervals. This data warehouse contains historical information that enables analysis of business performance over time.

CARS encompasses a set of defined tools, techniques, and processes and has been in production since 2007. It provides reporting capabilities throughout the center allowing access to critical business data. Additional background information about CARS can be found in Appendices C and D.

1.4 Other CDRH IT Systems Separately, CDRH has two other major groups of IT systems that include some level of interaction or exchange with the CSTAR suite of applications:

· CeSub - Center Electronic Submission Business (CeSub) Process Automation contract. Suite of applications operated and enhanced under a separate contract by another contractor.

· eCIRS/APPS – Enhanced CDRH Information Retrieval System (Oracle Applications). Legacy data entry applications and databases operated and maintained by government personnel.

Both the operations and maintenance and the enhancements to the CSTAR suite of applications (CTS and CARS) will involve working cooperatively with these other teams. These teams consist of Government Program Managers and various contractors. The level of effort may result from systems upgrades, patches to White Oak Data Center (WODC) and Contract Hosted Data Center (CHDC), new processes by the Office of Information Management (OIM) and be several hours but generally not more than one day, which occurs sporadically.

2. Objectives and Scope

2.1 Objective

The objective of this contract is to provide full software development life cycle support for the existing CSTAR applications, as introduced in Sections 1.2 and 1.3, along with any new CSTAR applications or capabilities developed in accordance with the following business objectives.

2.1.1 Innovation Business Objective

The Center requires expertise from its IT support contractors in the areas of information management and information technology in order to propose new and innovative approaches and technology applications. Application of this expertise will enable the Center to drive down costs, improve efficiency, enhance transparency, support business agility, improve services to stakeholders and the public, manage/improve performance, and continually innovate.

2.1.2 Premarket Data Entry Business Objective

As the Center moves to increase the number of premarket submissions received electronically and prepares for the reauthorization of the Medical Device User Fee and Modernization Act (MDUFMA), it may need to modify or even fully replace one or more of the underlying premarket data entry applications and databases. Fundamentally, the existing premarket data entry systems for the Document Control Center (DCC) and Program Operations Staff (POS) have used the same technology since the 1990s. This legacy premarket database architecture has hindered the CDRH’s ability to respond to changing business requirements.

2.1.3 Workload Management and Tracking Business Objective

Nearly every CDRH office tracks assignments and workflow steps for its core regulatory business processes. The Center plans to strengthen premarket review, align scientific resources, optimize meaningful data collection, enhance compliance capabilities, and improve guidance and regulations development. Therefore, the existing workflow tracking tool will need to be enhanced, augmented, and reworked. It must support new tracking items, changes to business processes, additions to structured data collection, modifications to business rules, and improvements associated with interacting with the electronic document repository.

2.1.4 Business Process Management (BPM) and Process Analytics Business Objective

Many of the Center's core business processes still involve manual, labor-intensive human tasks that would benefit from workflow automation, process standardization, and automatic notifications. Furthermore, CDRH seeks the flexibility and agility to improve and adapt business processes to the rapidly changing device market and regulatory landscape. The Center requires the investigation, evaluation, and addition of Business Process Management (BPM) and Business Activity Monitoring (BAM) technologies and capabilities into its suite of CSTAR applications. Specifically, the Center desires technologies for managing the entire lifecycle of a process (design, enact, analyze, control) and for providing real-time and up-to-date metrics as people work.

2.1.5 Knowledge Management/Collaboration Business Objective

The Center is in the planning stages to establish a sustainable program of knowledge management (KM). The Center anticipates expanding the capabilities of its document management implementation to provide: an improved user interface and experience, capabilities for uploading documents/files from a variety of sources/applications, more fully leveraging metadata in various ways, implementing a capability to search content that leverages metadata and other capabilities beyond basic full-text indexing (e.g. text mining), and implementation and utilization of taxonomy(ies) and “folksonomy” support. Work under this contract will be fully cognizant of KM initiatives and opportunities within the Center and incorporate them into the planning for system improvements.

2.1.6 Electronic Document Workplace Business Objective

The Center requires the ability to route documents and sign-off electronically as part of business processes within the Center's tracking system. This must occur in concert with the other contractors who maintain CDRH's electronic document repositories. The documents would only be permitted to be changed through strict change procedures, and the electronic signature would be considered legally binding and an official action. It is expected that this could facilitate the posting of this information on FDA’s public website automatically. The Center expects some of this work to have been started before award of this contract.

2.1.7 Electronic Industry Data Collection Business Objective

FDA is embarking on a major campaign to revise its regulations to increase the use of electronic information in the way it conducts business. On its immediate agenda are regulatory revisions to permit electronic submission of industry data, such as manufacturer device information and premarket submissions, to FDA and CDRH. To support these regulatory requirements, the Center may need to build, augment, complement, or maintain an IT infrastructure that supports the receipt, processing, routing, and review of industry submissions and other industry data.

2.1.8 Electronic Health Records and Use of Health Level 7 (HL7) Business Objective

Nationally, there is tremendous emphasis on Electronic Health Records and exchange of health information via standard messages and vocabularies. CDRH contains valuable public health information that is a critical component of electronic health information. Every electronic regulatory submission to CDRH is a potential candidate for standard message receipt/transfer. CDRH is involved with the HL7 organization in development, evaluation, and implementation of electronic messaging standards. CDRH has implemented HL7 ICSR Version 3, Release 1 message to receive adverse event reports and is working to adopt other HL7 standards. Work under this contract will be fully cognizant of this initiative within the Center for influence on its development planning.

2.1.9 Business Intelligence (BI) Business Objective

The Center requires reporting tools for searching through historical data about medical devices, facilitating a Total Product Life Cycle (TPLC) approach, comparing actual staff activities against regulatory performance criteria, generating Center-wide scorecards, and responding to Congressional and industry inquires. CARS is a repository of historical and current business operations data with the objective of being improved to provide enhanced decision support to analysts and management. The functions to be integrated include better reporting, operational and statistical analytics, data mining and profiling capabilities for information discovery, additional business performance management functions with dashboards and scorecards for metrics tracking, and improved data visualization tools to support analysis and communicating information through a graphical means.

2.1.10 FDA ORA IT Systems Integration Business Objective

Compliance activities for medical devices and radiation-emitting products, such as inspections and investigations, often require coordination with people in the field. These employees are part of FDA’s Office of Regulatory Affairs (ORA), which has separate and independent IT systems for field operations staff. CDRH needs to improve and enhance how its IT systems interact and exchange information with ORA’s IT systems. These activities will require specific coordination with ORA stakeholders to ensure that business needs are met by both CDRH and ORA.

2.1.11 Support of CDRH Initiatives Business Objective

The Center uses multiple contractors to meet the wide range of services and knowledge required to keep the Center operating smoothly and efficiently with its IT systems. Systems must communicate and interact with one another often to accomplish all the work required by the Center. Furthermore, many of the Center’s subsystems are linked to or integrated with other subsystems created or managed by other contractors to perform essential. Therefore, the contractor may be tasked with discrete work that supports systems that may integrate with the CSTAR suite of applications and legacy APPS databases (including new or existing systems) with the proviso that such tasking does not duplicate or conflict with tasking given to other contractors. This contractor may also perform integration and bridging work during the transition of contractors on other contracts supporting the Center with the approval of the FDA COTR/Project Manager should that become necessary.

2.2 Scope

The contractor shall provide software development life cycle support services for new and existing CSTAR applications, based on Objectives listed in Section 2.1, which support the automation of CDRH activities. All software development activities must be in accordance with the FDA Enterprise Performance Life Cycle (EPLC), which is discussed further in Appendix E. The scope of this contract includes:

1. Project management (PM) support services necessary to support the execution of the contractor’s approach to the technical activities performed under this contract and to report status to the FDA COTR/Project Manager and CDRH business management.

2. Steady state operations and maintenance (O&M) of the current CSTARS applications, including enhanced or new applications (custom or COTS). O&M activities include ongoing production, test, and development maintenance support; help desk support; data corrections; software upgrades; and minor enhancements.

3. Development, modernization, and enhancement (DME) work activities. The contractor shall provide the technical services necessary to design, develop, test, and implement additions and enhancements to the CSTAR suite of applications.

4. Transition work activities. The contractor shall facilitate the transition in and transition out of development and O&M activities for the CSTAR suite of applications.

The Government will issue task orders against this CSTAR contract for the ongoing O&M/PM support and new DME work of the CSTAR suite of applications.

3. Task Area Descriptions

3.1 Project Management Support

The contractor shall provide the project management services necessary to plan, structure, coordinate, schedule, manage, communicate, report, and steward CSTAR tasks, projects, and applications throughout the contract’s period of performance. The contractor shall provide both contract-level and task order level project management to establish control, management, monitoring, and notification mechanisms and shall work with the Government’s IT Project Managers and Business Project Managers to ensure that CSTAR projects stay on track and important milestones are met. Representative activities include:

· Base contract administration;

· Task order receipt and response;

· Task order staffing;

· Develop and maintain management plans throughout the period of performance, modifying and updating the plans as necessary;

· Develop and maintain work breakdown structures (WBS) for projects;

· Prepare monthly progress and financial reports;

· Conduct and participate in progress meetings;

· Facilitate Configuration Control Board (CCB) meetings;

· Develop meeting minutes;

· Provide artifacts for the Enterprise Architecture (EA) repository;

· Respond to ad hoc data calls;

· Contribute to Earned Value Management (EVM) reporting. CSTAR is currently categorized as a Tier 2 investment. HHS Guidance on EVM requirements can be found at http://www.hhs.gov/ocio/policy/20050004001.html#table1

3.2 Operations and Maintenance (O&M) / Steady State (SS) Work Activities

The contractor shall maintain the functionality, reliability, availability, performance, stability, sustainability, and security of the CSTAR suite of applications, including all incorporated software. The contractor shall identify, track, and analyze enhancement requests, bugs, and other issues as Change Control Requests (CCRs). The contractor shall perform minor development activities to implement enhancement requests approved by the CSTAR CCB. The contractor shall maintain, support, and evolve code, scripts, designs, documentation, reports, and templates. The contractor shall analyze and report on the impact of infrastructure, software upgrades, capacity, and other changes to the CDRH IT environments. Deliverable products shall be validated and tested to ensure that they meet applicable/specified standards, policy, business requirements, and quality measures.

CSTAR O&M also includes day-to-day operations, maintenance, and help desk support to ensure that the systems perform their intended functions. Representative activities include:

· System administration;

· Maintenance of EPLC artifacts and other system documents;

· Performance monitoring and tuning;

· Release management;

· Implementation of CCRs approved by the CSTAR CCB;

· Risk assessment and management;

· Maintenance of security accreditation;

· Data quality assurance;

· Support of system hardware and infrastructure upgrades;

· Configuration management;

· Tier 2/3 Help Desk support and issue tracking;

· User training.

3.3 General IT Lifecycle Support for Development, Modernization, and Enhancement (DME) Work Activities

The contractor shall provide full life cycle support to enhance, augment, modernize, or even create new CSTAR applications to meet CDRH’s evolving program needs and strategic goals. Any work activity that adds significant new functionality to existing systems, modernizes existing interfaces, replaces legacy applications, or involves brand-new initiatives would be considered a Development, Modernization, and Enhancement (DME) task. The CDRH Information Management Steering Committee (IMSC) is responsible for reviewing and prioritizing all DME activities. The Government will issue task orders for DME work.

The contractor shall work within established FDA guidelines and standards. All software activities will be, at a minimum, in accordance with FDA’s EPLC policies, processes, and templates. The Government will provide updates to artifacts (standards, document templates, and processes) as they become available. As the EPLC artifacts are modified, the contractor shall use the modified artifacts in all subsequent development activities. All software shall be developed in accordance with sound and acceptable software engineering industry best practices. All software delivered shall be optimized for performance and resource utilization for FDA’s production environment. All software developed shall maintain existing database integrity, error handling, and graceful termination of execution for unexpected problems and not adversely impact other applications running in the production environment.

CDRH anticipates that CSTAR DME work activities and funding will vary from year-to-year, with the expectation that there may be one to two DME work activities per fiscal year.

3.4 Transition Work Activities The contractor shall facilitate the transition in and transition out of development and O&M activities for the CSTAR suite of applications. It is the responsibility of the incoming contractor to ensure a smooth transition from the incumbent (outgoing contractor). The purpose of the transition is to transfer expert knowledge, data, and artifacts that are used to support applications from the incumbent contractor to the FDA (or its designated contractors) efficiently and orderly. The contractor shall develop both Transition In and Transition Out plans and documents.

4. Inspection and Acceptance The FDA COTR/Project Manager and CDRH business management shall inspect all deliverables submitted under this contract. The contractor may assume acceptance of a deliverable unless otherwise indicated in writing within 10 business days of receipt. In the event that a deliverable is not accepted, the contractor has five (5) business days to update and resubmit the deliverable.

5 Personnel 5.1 Staffing

The contractor is responsible for providing personnel with the management, technical, and subject matter expertise required to meet the objectives of this contract. Key personnel will be identified in task orders.

The contractor shall provide personnel/staff that is adequately trained and who have attained knowledge necessary for the performance of the client requirements. The contractor shall provide a Staffing Plan that details the personnel proposed across each task by Center.

All contractor assigned to this contract must provide verification of completion of all mandatory FDA training, including Annual Security Awareness Training.

6. Constraints

6.1 Technical Standards and Guidelines

Current standards and guidelines that must be considered in the execution of this contract include, but are not limited to, the following:

· Must conform to ICT21 Architecture

The Information and Computer Technologies for the 21st Century (ICT21) investment will enable the FDA, through the development of an agency-wide bioinformatics initiative, to strengthen product development and approval, improve manufacturing and product quality, strengthen post-approval surveillance and safety, support electronic prescribing, and improve clinical decision support. All CDRH IT systems must utilize FDA’s core infrastructure services and follow the established processes and procedures supported by the FDA in the White Oak Data Center (WODC) development and test and Contractor Hosted Data Center (CHDC) pre-production and production environments.

Note: Please refer to Appendix F for more information.

· Must comply with FDA approved technologies list

The FDA Master Approved Technology List (MAT) contains a list of approved technologies, including applications (software), infrastructure and peripherals (hardware), and also scientific software and devices. For any technology or software not currently on the MAT list, FDA’s Office of Information Management (OIM) must provide its approval through the “IT Standards and the IT Investment Management (ITIM)” process.

Note: Will provide upon contract award.

· Must comply with the FDA Security Authorization process, which closely resembles NIST SP800-37

Link - http://www.nist.org/nist_plugins/content/content.php?content.41 Security Authorization is the approach FDA follows to fulfill Federal Information Security Management Act (FISMA), Office of Management and Budget (OMB) and Department of Health and Human Services (HHS) requirements to ensure that information resources have adequate security to protect the Confidentiality, Integrity and Availability of information collected, processed, transmitted, stored, or disseminated by the agency.

See also: SP 800-37 Rev. 1: Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach

· Security controls must comply with NIST SP800-53

Link - http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf

This publication was developed by the Joint Task Force Transformation Initiative Interagency Working Group with representatives from the Civil, Defense, and Intelligence Communities in an ongoing effort to produce a unified information security framework for the federal government— including a consistent process for selecting and specifying safeguards and countermeasures (i.e., security controls) for federal information systems.

See also: SP 800-53 Rev. 3: Recommended Security Controls for Federal Information Systems and Organizations

· Must comply with all FISMA, NIST and OMB Laws and Regulations.

FISMA The E-Government Act (Public Law 107-347) passed by the 107th Congress and signed into law by the President in December 2002 recognized the importance of information security to the economic and national security interests of the United States. Title III of the E-Government Act, entitled the Federal Information Security Management Act (FISMA) requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source.

Link - http://csrc.nist.gov/groups/SMA/fisma/index.html NIST The E-Government Act [Public Law 107-347] passed by the 107th Congress and signed into law by the President in December 2002 recognized the importance of information security to the economic and national security interests of the United States. Title III of the E-Government Act, entitled the Federal Information Security Management Act of 2002 (FISMA), included duties and responsibilities for the Computer Security Division in Section 303 “National Institute of Standards and Technology.”

Link - http://csrc.nist.gov/publications/PubsSPs.html OMB The core mission of OMB is to serve the President of the United States in implementing his vision across the Executive Branch. OMB is the largest component of the Executive Office of the President. It reports directly to the President and helps a wide range of executive departments and agencies across the Federal Government to implement the commitments and priorities of the President.

As the implementation and enforcement arm of Presidential policy government-wide, OMB carries out its mission through five critical processes that are essential to the President’s ability to plan and implement his priorities across the Executive Branch.

Link – http://www.whitehouse.gov/omb/

· Must comply with HHS information Security Program: Contractor Oversight Guide – Section 2, Defining Contractor Systems and Related Security Requirements Information systems subject to Departmental and Federal requirements are predominantly maintained by Department personnel within HHS facilities; however, there exist a substantial number of contractor-run systems. This section is intended to clarify security requirements for these contractor-based systems as well as define the related roles of contractors and Departmental personnel.

For the purposes of this section, a contractor system is defined as any general support system, major application or minor application hosted or maintained by contractor staff including information systems used or operated by a contractor of an agency or other organization on behalf of an agency. [1] This includes all systems physically or logically located within the boundaries of contractor facilities, including government and non-government entities, and systems which reside within HHS boundaries but the primary support for which is delivered by contractor staff.

For further information see: Contactor Oversight Guide Section 2: Defining Contractor Systems and Related Security Requirements http://csrc.nist.gov/groups/SMA/fasp/documents/c&a/HHS_Security_Test_andEvaluation_Guide_08242005.pdf

· Must comply with FDA 3250 series of SMG policies, as well as HHS security policies. Note: SMG 3251.4 Outsourcing and Third Party Arrangements

The FDA Staff Manual Guides (SMGs) are the Agency directives that document organizations and functions; delegations of authority; and administrative and program policies, responsibilities and procedures. A directive is a written communication issued in an organized system to establish organizations, delegations, policies, responsibilities, or procedures; to require action; or to set forth information needed for the effective operation of the system.

Note: Will provide upon contract award.

7. Conformance with Applicable Laws, Regulations, Policies, and Standards

7.1 Contractor Compliance

The contractor shall be responsible for knowledge of and compliance with all applicable federal information technology and information management laws, regulations, policies, and standards at the government-wide, HHS, and FDA levels. At the government-wide level, these include Office of Management and Budget (OMB), National Institute of Standards and Technology (NIST), and General Accounting Office (GAO). These can be primarily found at or through the Federal CIO Council website at: http://www.cio.gov/. HHS documents are found at http://www.hhs.gov/oirm/.

7.2 508 Standard Requirements

Pursuant to Section 508 of the Rehabilitation Act of 1973 (29 U.S.C. 794d) as amended by Public Law 105–220 under Title IV (Rehabilitation Act Amendments of 1998), all Electronic and Information Technology (EIT) developed, procured, maintained, and/or used under this contract shall be in compliance with the ‘‘Electronic and Information Technology Accessibility Standards’’ set forth by the Architectural and Transportation Barriers Compliance Board (also referred to as the ‘‘Access Board’’) in 36 CFR part 1194. The complete text of Section 508 Final Standards can be accessed at http://www.access-board.gov/sec508/standards.htm.

The standards applicable to this requirement are:

Subpart B, 1194.21 Software applications and operating systems

(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.

(b) Applications shall not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer.

(c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.

(d) Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text.

(e) When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application's performance.

(f) Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes.

(g) Applications shall not override user selected contrast and color selections and other individual display attributes.

(h) When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user.

(i) Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

(j) When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels shall be provided.

(k) Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz.

(l) When electronic forms are used, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

Subpart B, 1194.22 Web-based intranet and internet information and applications

(a) A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).

(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

(d) Documents shall be organized so they are readable without requiring an associated style sheet.

(e) Redundant text links shall be provided for each active region of a server-side image map.

(f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

(g) Row and column headers shall be identified for data tables.

(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

(i) Frames shall be titled with text that facilitates frame identification and navigation.

(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

(k) A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.

(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

(m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).

(n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

(o) A method shall be provided that permits users to skip repetitive navigation links.

(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

Subpart C, 1194.31 Functional Performance Criteria

(a) At least one mode of operation and information retrieval that does not require user vision shall be provided, or support for assistive technology used by people who are blind or visually impaired shall be provided.

(b) At least one mode of operation and information retrieval that does not require visual acuity greater than 20/70 shall be provided in audio and enlarged print output working together or independently, or support for assistive technology used by people who are visually impaired shall be provided.

(c) At least one mode of operation and information retrieval that does not require user hearing shall be provided, or support for assistive technology used by people who are deaf or hard of hearing shall be provided.

(d) Where audio information is important for the use of a product, at least one mode of operation and information retrieval shall be provided in an enhanced auditory fashion, or support for assistive hearing devices shall be provided.

(e) At least one mode of operation and information retrieval that does not require user speech shall be provided, or support for assistive technology used by people with disabilities shall be provided.

(f) At least one mode of operation and information retrieval that does not require fine motor control or simultaneous actions and that is operable with limited reach and strength shall be provided.

Subpart D, 1194.41 Information, Documentation, and Support

(a) Product support documentation provided to end-users shall be made available in alternate formats upon request, at no additional charge.

(b) End-users shall have access to a description of the accessibility and compatibility features of products in alternate formats or alternate methods upon request, at no additional charge.

(c) Support services for products shall accommodate the communication needs of end-users with disabilities

Appendix A – CTS Application Description

As explained in Section 1.2, CTS is a web-based, workload management and tracking system. CTS helps CDRH ensure more accurate, more efficient, and faster review of industry submissions. It provides a detailed history of the tracking actions taken on various documents and review processes within CDRH.

Although users see CTS as a single system, it is divided into the following subsystems, or modules. Subsystems may be logically separate, but modules share much of the same code when functionality is similar.

· DTS (Core) – Division Tracking System. The original version of CTS released for CDRH. Also known as “Core” because of the initial functionality that is utilized by other subsystems. Used by the Office of Device Evaluation (ODE) and the Office of In-Vitro Diagnostic Devices (OIVD) to keep track of reviews for 510(k) clearances, Premarket Approvals (PMAs), Investigational Device Exemptions (IDEs) and other premarket submission types.

· CLIA – Clinical Laboratory Improvement Act. Used by OIVD to track Clinical Laboratory Improvement Act (CLIA) categorizations, reviews, and related special documents, including CLIA Waiver Requests.

· COPS – Compliance Operations Program Support. Used by the Office of Compliance (OC) to track Recall actions, Establishment Inspection Reviews (EIRs), Complaints, Good Manufacturing Practice (GMP) reviews, Warning Letters, and more.

· DNMS – Device Nomenclature Management System. Used by all CDRH offices to request, approve, and query product classification codes (a.k.a. ProCodes).

· eConsult – Electronic Consultation Request. Used by all of CDRH to request and track consults electronically. Inter-office consultations are completed for a variety of work products requiring expertise, including premarket device submissions, post-approval studies, and compliance and enforcement actions. Consults may be associated with a regulatory review or may be standalone. Workflows for consults vary depending on the rules that have been established by the receiving organization or type of consult.

· eRadHealth – Electronic Radiation Health. Used by the Office of Communication, Education and Radiation Programs (OCER) to track reports and correspondence received from manufacturers of non-medical, radiation-emitting products.

· GEN Documents – Generic Document Tracking. Provides a simple way to track work activities in CTS when the development of a dedicated subsystem is not planned or feasible.

· PAS/COATS – Post Approval Studies/Conditions of Approval Tracking. Used by the Office of Surveillance and Biometrics (OSB) to track required post-approval studies of approved devices.

· PSS – Post Surveillance Studies. Used by OSB to track the reporting status of active 522 post-surveillance studies.

· RFD – Request for Designation. Used by FDA’s Office of Combination Products (OCP) to track Requests for Designation (RFDs) that determine the regulatory identity of a product (i.e., drug, device, biological product, or combination product) and/or which Center will have primary jurisdiction for premarket review and regulation of a combination product.

CTS enables CDRH to comply with the FDA Modernization Act of 1997, FDA Amendments Act of 2007, Clinical Laboratory Improvement Amendments (CLIA) of 1988, and other key regulatory requirements. CTS supports review processes within all CDRH offices and also includes connections to the Office of Regulatory Affairs (ORA). CTS has won two FDA special recognition awards since its launch in February 2004.

Appendix B – CTS Technologies and Development Tools

The core technologies behind CTS include Apache Tomcat servers, the Java JDK v1.5 framework, nearly 70 Java libraries, Oracle 10g databases, and other open source tools. The following table is a listing of CTS technologies and development tools:

CTS Technologies and Development Tools

ieHTTPHeaders

Internet Explorer plug-in that shows HTTP headers

Java STRUTS

CTS application framework

JavaScript

Client-side scripting

MS Remote Desktop Connection 2

Virtual server administration

Traction

Document repository and collaboration

Visio

Business workflow design for generic documents

XML

Custom report feature

Appendix C – CARS Application Description

CARS is a business intelligence and data warehousing solution based on Business Objects, which provides CDRH staff members with tools to upgrade their analysis and reporting capabilities. It simplifies access to hundreds of data elements located in tens of independent systems for ad-hoc queries, user-defined reports, and canned reports. CARS enables CDRH to comply with the Medical Device User Fee Act (MDUFA) requirements of the FDAAA of 2007. CARS leverages FDA-standard, off-the-shelf technologies, and an open source data integration suite for Extraction, Transformation, and Loading (ETL). Automatic scripts invoke the ETL software to refresh the Oracle 10g data warehouse every night. The warehouse structure reflects the “data vault” approach and makes data available to Business Objects universes, predefined Web Intelligence documents, and Crystal Reports. Custom SQL programs verify that each nightly refresh is successful.

The joint government-contractor CARS team received the FDA Outstanding Service Award for 2008. Team members perform a spectrum of tasks to update CARS two to three times each year, including database re-engineering, data profiling, ETL design and development, Crystal Reports design and development, ad-hoc query universe design and development, and training.

Appendix D – CARS Technologies and Development Tools

The following table is a listing of CARS technologies and development tools:

CARS Technologies and Development Tools

ERD Concepts 5

Data modeling

Oracle Data Modeler

Data modeling

Traction

Document repository and collaboration

Appendix E – FDA EPLC (See EPLC Overview for a full description of the FDA EPLC, which is located on the zip file provided) All work performed under this contract will support FDA’s Information Technology Governance Framework, a systematic and uniform methodology for information systems development and the FDA IT reorganization program and initiatives. Project objectives shall be fulfilled in a stage driven manner and shall encompass the following stages in Appendix E.

· Initiation – During the Initiation Stage, defined business needs for which a technological solution is required are evaluated and a preliminary enterprise architecture review is conducted to determine if there is sufficient justification to proceed into the Concept Stage. The Initiation Stage may be triggered because of business process improvement activities, changes in business functions, advances in information technology, or may arise from external sources, such as public law or the public. When an opportunity to improve business/mission accomplishments or to address a deficiency is identified, the Business Owner and the Project Manager (if already assigned) document these opportunities in the Business Need Statement. The Architecture Review Board examines whether the proposed project potentially duplicates, interferes, contradicts or can leverage another investment that already exists, or is proposed, under development, or planned for near-term disposition. Sufficient high-level functional requirements are required to understand what the project is intended to do and how it supports the business need.

· Planning – This Stage requires study and analysis culminating in the full Project Management Plan that may lead to system development activities. The project work is broken down into specific tasks and sub-tasks (the Work Breakdown Structure [WBS]), including the identification of project deliverables and assignment of allocated resources to each task. Control documents relating to that effort are produced. The degree of project management rigor that is to be applied to the project is determined and milestones are established. Specific plans for management and governance of the project are established and documented to guide ongoing project execution and control. The Planning Stage ends with a formal review during which the adequacy of the Project Management Plan is determined.

In the planning stage, sufficient requirements detail is required to support the development of the project’s Project Management Plan.

· Requirements – During the Requirements Analysis Stage, the business (project in-scope) requirements that were previously documented in an earlier stage are revalidated and further analyzed and decomposed into high-level system (functional and non-functional) requirements that define the automated system/application in more detail with regard to inputs, processes, outputs, and interfaces. If appropriate, a logical depiction of the data entities, relationships and attributes of the system/application is also created. During the Requirements Analysis Stage, the initial strategy for testing and implementation is also begun. In addition, the work planned for future stages is redefined, if necessary. The Requirements Analysis Stage ends with a review to determine readiness to proceed to the Design Stage.

Detailed application requirements (both functional and non-functional) are required to permit detailed project management planning, execution and control. If detailed requirements and subsequent planning identify a breach of the investment-level cost, schedule or performance baselines established at the end of the planning stage, a formal change to the Investment Baselines will be requested.

· Design and Development – The Design Stage seeks to develop detailed specifications that emphasize the physical solution to the user's information technology needs. The system requirements and logical description of the entities, relationships, and attributes of the data that were documented during the Requirements Analysis Stage are further refined and allocated into system and database design specifications that are organized in a way suitable for implementation within the constraints of a physical environment (e.g., computer, database, facilities).