Additional_Terms_and_Conditions.doc

Indian Health Service

Request for Proposal For

Health Information Technology Systems & Support (HITSS)

Interoperability Platform & Application Suite

Software Engineering & Development Life Cycle Support Services

(RFP) 19-236-SOL-00012

You are invited to submit a proposal in accordance with the requirements of the following Solicitation.

Proposals must be received by the Government no later than the local time on the Due Date stated in the table below.

(301) 443-4470 paul.premoe@ihs.gov

Section B – Products or Services and Prices/Costs

B.1.

CONSIDERATION

The Contractor shall provide the commercial services described in Section C, Description/ Specifications/Performance Work Statement (PWS). Except as otherwise specified in the contract, the Contractor shall furnish the necessary personnel, equipment, materials, services, and otherwise do all things necessary for the performance of the work set forth herein.

B.2. CONTRACT PRICING SEQ CHAPTER \h \r 1 The Indian Health Service (IHS) is planning to issue a labor-hour contract vehicle as a result of this solicitation. The requirement is being solicited among Small Indian Firms only pursuant to The Buy Indian Act, 25 U.S.C. 47. See HHSAR Subpart 326.6—Acquisitions Under the Buy Indian Act for ownership and subcontracting requirements. You are invited to submit a written proposal utilizing the below Schedule of Prices for the services specified in Section C, under Request for Proposal (RFP) 19-236-SOL-00012.

Schedule of Prices Base Year: 12 Months Period CLINs

Base Labor

*See B.4.

(OPTIONAL CLINS)

CLINs

Optional Labor

*See B.4.

Option Year I: 12 Months Period

CLINs

Base Labor

*See B.4.

CLINs

Optional Labor

*See B.4.

Option Year II: 12 Months Period

CLINs

Base Labor

*See B.4.

CLINs

Optional Labor

*See B.4.

Option Year III: 12 Months Period

CLINs

Base Labor

*See B.4.

CLINs

Optional Labor

*See B.4.

Option Year IV: 12 Months Period

CLINs

Base Labor

*See B.4.

CLINs

Optional Labor

*See B.4.

B.3.

TRAVEL LINE ITEMS

Travel Line items shall be treated as part of the effort for the purposes of this contract and shall be handled in the following manner. The Contractor will notify the COR of the requirement at least 30 business days prior to the scheduled travel. Upon COR’s approval, the Contractor shall prepare a proposal reflecting the actual cost of the items and submit it to the COR within 5 business days. The pricing for the proposal shall be based on the commercial catalog pricing and receipts of the all items over $300 shall be included with the invoice.

The Contractor shall be reimbursed for travel costs in accordance with FAR 31.205-46.

Local. The cost of local travel, meal, and/or incidental expenses cost will not be reimbursed for Contractor performance when involving local travels.

Non-local. In the event that non-local travel is required, the Government will reimburse the cost via appropriate contract line item.

Section C – DESCRIPTION/SPECIFICATIONS

PERFORMANCE WORK STATEMENT (PWS)

Health Information Technology Systems & Support (HITSS)

Interoperability Platform & Application Suite

Software Engineering & Development Life Cycle Support Services

Part 1

GENERAL INFORMATION

1. General: This is a non-personnel services contract to provide full lifecycle software development, architecture, and operations support services. The Government shall not exercise any supervision or control over the contract service providers performing the services herein. Such contract service providers shall be accountable solely to the Contractor who, in turn is responsible to the Government.

1.1 Description of Services/Introduction: The contractor shall provide all personnel, equipment, supplies, facilities, transportation, tools, materials, supervision, and other items and non-personal services necessary to perform full lifecycle software development, architecture, and operations support services as defined in this Performance Work Statement (PWS) except for those items specified as government furnished property and services. The contractor shall perform to the standards in this contract.

1.2 Background: The Indian Health Service (IHS) develops and supports a comprehensive integrated health information system of systems for the use in the delivery of patient care at IHS, Tribal and Urban (I/T/U) hospitals and clinics across the country. The health information technology systems and support ‘ecosystem’ (HITSS) is comprised of a mix of distributed and centralized computing systems often generally referred to as the Resource and Patient Management System (RPMS). Distributed applications within the RPMS are similar to the Veterans Administrations (VA), Veterans Health Information Systems and Technology Architecture (VistA) and are deployed in the MUMPS (InterSystems Caché\Ensemble) database architecture using VA utilities. These distributed applications include a number of graphical user interfaces (GUI) built in various programming languages, ranging from Delphi to C# .NET using broker based or web services. Centrally hosted are the HITSS interoperability applications (formerly known as ‘RPMS Network’) for which this PWS will support. The suite of HITSS interop applications include: Master Patient Index (MPI), Health Information Exchange (HIE), Personal Health Record (PHR), Secure Direct Messaging, Distributed Terminology Services (DTS), central Electronic Prescribing (eRx). The IHS looks to continue support of these legacy applications while preparing for their potential replacement, as well as evolve the centrally hosted HITSS solutions.

The RPMS is recognized as a Certified Electronic Health Record Technology (CEHRT) for inpatient and ambulatory settings according to the 2014 version certification criteria published by the Office of the National Coordinator (ONC) for Health Information Technology (HIT). The modules associated with the work in the PWS are applications that support the CEHRT and subject to recertification upon change in functionality.

1.3 Objectives: The objectives of this contract are to:

a. Provide software application development services for the HITSS Interoperability Application Suite. This will include all activities of the software development lifecycle (i.e., requirements elicitation, design, development, integration & test, operations & maintenance services);

b. Provide Engineering Services for new application development and/or Commercial-Off-The-Shelf (COTS), Government-Off-The-Shelf (GOTS) software integration in support of the HITSS Interop Application Suite and evolving Electronic Health Record and Health Information Exchange Technologies;

c. Provide application administration support services for the HITSS Interop applications;

d. Provide Software Security Architectural Services for HITSS Interop Application Suite.

The work to be performed requires the application of software engineering best practices, quality software development and configuration control, lifecycle management, structured and adaptive software development life cycle (SDLC) methodologies, and use of computer assisted software engineering tools and practices. The key areas of focus will support those applications and services of the HITSS Interop Platform and will include but are not limited to the following:

a. Architecture design and enhancement

b. Application support services

c. Database administration

d. Configuration and Services Management

e. Software Development Project Management

f. Align IHS software lifecycle programs and processes with current best practices in application architecture, design, and management

g. Requirements elicitation, systems analysis, design modeling and documentation, and coding

h. Transition to a true Service-Oriented Architecture (SOA)

i. Transition disparate GUIs into a common interface framework compliant with accessibility and usability best practices in a platform-independent context (e.g., support for Web, mobile, machine, assistive technology, and other ancillary interfaces)

j. Maturing processes and models related to IT governance, project and portfolio management, system development lifecycle, security integration, and software quality assurance

1.4 Scope: This PWS identifies eight (8) major Task Areas that may include performing one or more Functional and Programmatic Activities identified in section 5.1 as part of each task area. Task areas are mixed-lifecycle software applications and may require mixed method software development approaches. The Contractor shall furnish all of the necessary personnel, materials, services, facilities, (except as otherwise specified herein), a necessary for the performance of the work specific to the following:

TASK AREAS

A. Master Patient Index (MPI) Software Development and Maintenance

B. Health Information Exchange (HIE) Software Development and Maintenance

C. Personal Health Record Application (PHR) Development and Maintenance

D. Direct Secure Messaging Development Maintenance and Support

E. Central Electronic Prescribing (eRx) Development and Maintenance

F. Distributed Terminology System (DTS) Administration and Integration Support

G. HITSS Transition and Cut-over work (Optional Task)

H. Health Information Technology (HIT) Central Services re-engineering, Innovation and Development (Optional Task)

Functional and Programmatic Activities:

A. Basic Operations and Maintenance Services to Support the PWS Objectives

B. IT Architecture

C. Application Level Security Engineering and Compliance

D. Program Management Support

E. Software Engineering and Compliance

F. Project Management Support

G. Analysis and Design

H. Testing

I. Implementation and Deployment Support

J. Training and Documentation Support

K. User Support

L. System Administration

M. Subject Matter Expert Support

N. Quality Assurance

O. Project Documentation Support

P. Software Development Life Cycle (SDLC) Tools

Q. Transition Management

R. Contractor Management Reporting

1.5 Period of Performance: The Period of Performance (PoP) consists of 12 month base period, plus four 12 month optional periods.

1.6 General Information

1.6.1 Quality Control: The contractor shall develop and maintain an effective quality control program to ensure services are performed in accordance with this PWS. The contractor shall develop and implement procedures to identify, prevent, and ensure non-recurrence of defective services. The contractor’s quality control program is the means by which work is assured to comply with the requirements of the contract. The contractor’s proposal is an evaluation factor and three (3) copies of a comprehensive written Quality Control Plan (QCP) shall be digitally submitted to the Contracting Officer (CO) and Contracting Officer’s Representative (COR) within ten (10) calendar days of the start date of the contract and subsequently within five (5) days of a change to the plan thereafter. After acceptance of the QCP the contractor shall receive the contracting officer’s acceptance in writing of any proposed change to the contractor’s Quality Control (QC) system. The approach to QC should map to the contractor’s selected development methodology; however, it must also address support for Quality Assurance Surveillance Plan (QASP) reporting requirements.

1.6.2 Quality Assurance: The government shall evaluate the contractor’s performance under this contract in accordance with the QASP. The QASP is primarily focused on what the Government must do to ensure that the contractor has performed in accordance with the performance standards. It defines the performance standards, how the performance standards will be applied, and the frequency of surveillance. The government may use contractors, acting as agents of the government, to carry out QASP monitoring and reporting requirements.

PART 2

Acronyms/Definitions

PART 3

GOVERNMENT FURNISHED ITEMS AND SERVICES

3.1 Licenses, Products, and Equipment

1. …

2. …

3. …

4. …

5. …

6. …

7. …

8. …

9. …

10. …

11. …

Unless otherwise specified herein or in a particular Work Plan, the Contractor shall be responsible for providing all hardware, software, and software licenses required for its employees to carry out the work of the contract.

If an IHS specification requires the Contractor to have in its possession a particular medical device or other equipment not normally required for software development (such as a laboratory printer, EKG machine) in order to complete development and testing, the IHS will supply this equipment to the Contractor. The equipment remains the property of the Government and will be returned to IHS at the conclusion of the development task.

3.2 RPMS and VHA Software: The IHS will provide the Contractor with all released RPMS code necessary for the Contractor to fulfill the requirements of the contract. The Contractor may from time to time identify a need for access to an unreleased application or patch that is still in development. Such requests will be handled through the COR in collaboration with the IHS Software Quality Assurance (SQA) department on a case-by-case basis, the risk being that if the Contractor tests software against an unreleased package and that package changes before release, incompatibility may result.

The IHS will assist the Contractor as needed with obtaining software from the Veterans Health Administration (VHA) or other government entity if the request is determined to be necessary for the programming of IHS requirements.

3.3 RPMS Databases: The IHS will supply the Contractor from time to time with one or more databases obtained from and representative of a typical RPMS installation at an Indian Health Service or Tribal health care facility. Such databases will be “de-identified” by IHS according to OIT security policies before delivery to the Contractor. The purpose of such databases will be to ensure that all software is developed and tested in a representative system before being submitted for field testing. The IHS will provide the Contractor with an updated database within one month of contract award, and no less than annually thereafter throughout the period of performance.

PART 4

CONTRACTOR FURNISHED ITEMS AND RESPONSIBILITIES

4.1 General: The Contractor shall furnish all supplies, equipment, facilities and services required to perform work under this contract that are not listed under Part 3 of this PWS.

4.2 Materials: The Contractor shall furnish materials, supplies, and equipment necessary to meet the requirements under this PWS.

4.3 Equipment: The Contractor shall provide laptops, servers, software and all software development equipment necessary to meet the requirements under this PWS, unless otherwise indicated by the Government when Government Furnished Equipment (GFE) is called for.

PART 5

SPECIFIC TASKS

Task Areas:

5.0 Operations and Maintenance

The contractor shall provide fully qualified staff to support the full spectrum of software engineering and development activities. The primary work includes operations and maintenance, modification and enhancement of the existing HITSS Interoperability applications. Maintenance includes application level system management, database administration, minor code repair, user support staff augmentation. Project management and technical writing will be required to support software modification and enhancement projects. The expert level staff shall support the agency existing centralized HITSS Interop applications identified in the Task areas below. When executed by official contract action the contractor shall provide additional staffing resources as needed to support federally identified innovation or re-engineering and design projects for Centralized RPMS applications and database services – whether government-off-the-shelf (GOTS) or commercial-off-the-shelf (COTS) products (Tasks 7).

5.0.1 Master Patient Index (MPI) Software Development and Maintenance: The contractor shall perform services to support operations and maintenance and as directed by COR specific modifications, enhancement of existing and/or development of new capabilities to the IHS RPMS Master Patient Index system. MPI software operations must support accurate and prompt access to patient data across all critical segments of federal, tribal, and urban programs and facilitate interaction with private healthcare sectors to support care coordination through robust exchange of data.

The existing legacy master patient index system is a COTS solution (Proprietary to Nextgate Inc.) that consists of a database that contains information on every patient registered and participating in the IHS HITSS Interop Platform services. Its data consist of demographic elements such as patient names, date of birth, gender, race, social security number and place of residence, email, phone and other content. The MPI task here will require performance of functional and programmatic activities that include meeting short term and long term objectives.

5.0.2 Health Information Exchange (HIE) Software Development and Maintenance: The contractor shall provide services to support operations and maintenance and as directed by COR specific modifications, enhancement of existing and/or development of new capabilities to the IHS Health Information Exchange system. The HIE receives data in a Consolidated Clinical Document Architecture (CCDA) from decentralized RPMS environments. The work performed under this contract will support central HIE components that consist of the document registry, document repository, document viewer and gateway to other HIEs such as the Nationwide Health Information Network. The MPI integrates key patient identifiers and serves as a critical component to the HIE and interfaces between are considered in the support and maintenance of this task area. The technical foundation of the legacy HIE is a combination of SQL databases and Java user interfaces.

5.0.3 Personal Health Record (PHR) Development and Maintenance: The contractor shall provide services to support operations and maintenance and as directed by COR specific modifications, enhancement of existing and/or development of new capabilities to the IHS Personal Health Record system. PHR software needs to support accurate and prompt access to patient data across all critical segments of federal, tribal, and urban programs and facilitate interaction between patients and providers, and patients and access to their health care information. The PHR consist of the key components a SQL database that is accessed via an Administration Portal and the Patient Portal. Work shall include a combination of functional and programmatic activities listed in section 5.1.

5.0.4 Direct Secure Messaging Development Maintenance and Support (DIRECT): The contractor shall provide support and services for operations and maintenance and as directed by COR specific modifications, enhancement of existing and/or development of new capabilities to the Direct Secure Messaging suite. The IHS DIRECT secure messaging suite currently includes the following components, Certificate Directory with secure message transfer API and Private Key store. Enhancement work will include developing additional Directories and a combination of functional and programmatic activities listed in section 5.1.

5.0.5 Central Electronic Prescribing (eRX) Development and Maintenance: The contractor shall provide support and services for operations and maintenance and as directed by COR specific modifications, enhancement of existing and/or development of new capabilities to the central eRX software. The e-Prescribing software is a component that provides a mechanism for transmitting prescriptions electronically to third parties via the IHS Central Ensemble production and SureScripts. Messages transmitted between a local instance of the RPMS system and the central Ensemble productions are sent in HL7 version 5.1 format. Message transmitted between the central Ensemble production and SureScripts are in XML version 1.0 format. Enhancement work will include a combination of functional and programmatic activities listed in section 5.1.

5.0.6 Distributed Terminology Services (DTS): The contractor shall provide support and services to manage the content and operations of Apelon software to inlclude system updates of the terminology systems. The core terminology solution which is the Apelon DTS product implementation consists of consists of the following components: core terminology server, DTS Editor, a standalone application for managing the terminologies on the server, a web-based browser front-end for viewing terminology trees, import and migration utilities, API and Web Services to support application development. The contractor shall also provide support and services to manage and enhance and/or develop new capabilities to the IHS extensive custom SNOMED to ICD-10 map content.

5.0.7 HITSS Central Services Innovation Work (Optional Task): This task is an optional task and shall be supplemented with additional labor for the government to execute at any time during the life of the contract through an official contract modification. The contractor shall provide a team of personnel that will consult and provide support services to work with IHS representatives on innovation of HIT solution projects. The activity will include all or a few functional and programmatic activities outlined in section 5.1.

The scope of the innovation will encompass but is not limited to evaluation, innovation, and development of proof of concepts - specifically for HIT applications and services that may be centrally housed in the cloud or a Federal Data Center. This may include such innovations to any of the Interop Services Systems in terms of enhancements.

This task, though undetermined specifically, is crucial to the ongoing vitality and functionality of the overall Interop Services platform and may have direct impact to system performance or capability enhancing patient experience and patient quality of care. Such innovations may spawn from congressional mandate, market research, internal IHS needs, current limitations to be addressed, quality or security improvements, and potentially cost saving or cost avoidance measures.

5.0.8 HITSS Central Services Transition and Innovation Operationalization Work (Optional Task): This task is an optional task shall be supplemented with additional labor for the government to execute at any time during the life of the contract through an official contract modification. The contractor shall provide a team of personnel that will consult and provide necessary services to work with IHS representatives on transitioning innovation related work from legacy systems to modern systems within the scope of this contract. The activity will include all or a few functional and programmatic activities outlined in section 5.1.

5.1 Task Area Functional and Programmatic Activities:

Contractor shall support Task Areas 5.0.1 - 5.0.8 in performance capabilities with the provision of personnel who possess skill sets to perform the following, but not limited to:

A. comprehensive clinical terminology engineering and system administration

B. database management

C. electronic health records (EHR) COTS/GOTS federation

D. electronic prescribing engineering, development and system administration

E. health information exchange (HIE) {HITSS Interop Platform core application}

F. health information management (HIM)

G. health information technology (HIT)

H. master patient index (MPI) {HITSS Interop Platform core application}

I. middleware services

J. personal health record (PHR) {HITSS Interop Platform core application}

K. secure direct messaging {HITSS Interop Platform core application}

L. security patch testing

M. simplified authentication solution (SAS)

In addition, the Contractor shall provide fully qualified staff to support and assist IHS with evolving the HITSS software lifecycle programs and processes and to align them with current best practices in application architecture, design, deployment, and management. This includes the full software lifecycle development, architecture, operations support services assessments, interfaces, release management, configuration management and control, infrastructure development and maintenance services, customized solutions to satisfy specific site needs, deployment and software installation, training, verification, troubleshooting, Caché/Ensemble/HealthShare application development, quality assurance and control, and documentation.

5.2 IT Architecture

5.2.1 Enterprise Architecture: The Contractor shall provide enterprise architecture services, including the documentation of current state and future state business models, data models, application inventories, and technical design patterns in order to enable IHS to align its IT systems and infrastructure with IHS strategic priorities and plans. The Contractor shall also support federally and agency mandated reporting requirements.

5.2.2 Service-Oriented Architecture: The Contractor shall develop architectural deliverables (e.g., standards, design patterns, service catalogs, and technical interfaces) in order to support IHS’s intent to migrate to a more scalable, maintainable service-oriented architecture.

5.2.3 Sub-Task 2.3 Standards Development and Adoption: The Contractor shall document and achieve buy-in on the necessary data and technical standards to achieve the future state architecture.

5.3 Application Level Security Engineering and Compliance

5.3.1 Identity and Access Management (IAM): The Contractor shall provide technical application engineering services to support the development of a cohesive identity and access management strategy, which will enable IHS to achieve strategic aims in the areas of security, meaningful use, mobile health, patient access to health information, national interoperability of health information, and cloud computing – among others. In doing so, the Contractor must work collaboratively with other divisions within OIT, including the Division of Information Security, which specifies agency-level security requirements and policy, and the Division of IT Operations, which provides operational support and system administration for many of IHS’s current IAM capabilities, including directory services.

5.3.2 Compliance: Ensuring conformance of application architectures with FISMA, Privacy Act, and HIPAA requirements. The Contractor shall provide expert level services in the areas of designing, constructing, and implementing secure systems and supporting processes in order to protect the privacy, security, integrity, and availability of IHS systems, patients’ sensitive protected health information, and personal identifiable information.

5.3.3 Health IT certification: Given the important role of IHS systems in supporting the delivery of healthcare, the Contractor must provide expertise in order to ensure conformance with all industry health IT standards, health IT certification requirements, and Promoting Interoperability requirements (fka ‘Meaningful Use’). This task includes providing consulting services, policy development support, and standards conformance testing in the areas of health IT certification.

5.4 Program Management Support

5.4.1 Program Planning: The Contractor shall provide program planning support that enables the program level planning integration of many simultaneous projects and in support of a defined release management process. This task includes the staffing of an Agile Program Management Office (PMO) that is capable of integrating Agile and waterfall projects into an integrated and published product roadmap. At a high level, this task includes all activities related to program planning, program plan execution, program plan monitoring and controlling, program risk management, and program management of other project management process areas.

5.4.2 Product Roadmap Development: The Contractor shall develop, publish, and maintain an integrated, easy-to-understand product roadmap that depicts the integrated release of new capabilities, products, services, meta-processes, and significant infrastructure updates. The purpose of the roadmap is to serve as a stakeholder communication tool and to enable program integration of product iteration and release cycles.

5.4.3 Agile Portfolio Management: The Contractor shall provide for program level application and project portfolio management. This task includes but is not limited to: conducting earned value analysis, supporting the program’s capital planning and investment control (CPIC) reporting requirements in accordance with OMB and agency guidelines, supporting program budgeting activities (including budget formulation, execution, and review), supporting project cost accounting, implementing and maintaining project accounting systems, supporting program communications planning and execution, including the preparation and review of communication matrices, product marketing plans, written correspondence, and executive presentations.

5.4.4 Sub-Task 4.4 Policy Analysis: The Contractor shall provide health IT consulting services to support the development and review of federal, agency, and programmatic policies and standard operating procedures, especially in the areas of health information technology, health information management, and federal information systems management.

5.5 Software Engineering

The Contractor shall provide robust, high quality software development and engineering services in order to construct secure, reliable, and user-friendly clinical, administrative, infrastructure (middleware), integration, and IAM systems, using a combination web-based architectures, mobile application architectures, and cloud computing architectures and support and/or integrate with client-server architectures that are currently in use at IHS, Tribal, and Urban (I/T/U) facilities nationwide or that the Contractor develops in accordance with agency published standards. This task includes the development, documentation, review, and integration of source code, user interfaces, application program interfaces (APIs), web services, application and database scripts, routines, etc. It incorporates the principles of secure coding and Agile programming methods.

5.5.1 Secure Coding Best Practice: The Contractor (and/or any subcontractor) shall follow secure coding best practice requirements, as directed by United States Computer Emergency Readiness Team (US-CERT) specified standards and the Open Web Application Security Project (OWASP), that will limit system software vulnerability exploits.

5.5.2 Designed and Developed for End Users: The Contractor (and/or any subcontractor) shall ensure IT applications designed and developed for end users (including mobile applications and software licenses) run in the standard user context without requiring elevated administrative privileges.

5.5.3 Fully Functional and Operates Correctly: The Contractor (and/or any subcontractor) shall ensure that computer software developed on behalf of HHS or tailored from an open-source product, is fully functional and operates correctly on systems configured in accordance with government policy and federal configuration standards. The contractor shall test applicable products and versions with all relevant and current updates and patches updated prior to installing in the HHS environment. No sensitive data shall be used during software testing.

5.5.4 Sensitive Information Protection: The Contractor (and/or any subcontractor) shall protect information that is deemed sensitive from unauthorized disclosure to persons, organizations or subcontractors who do not have a need to know the information. Information which, either alone or when compared with other reasonably-available information, is deemed sensitive or proprietary by HHS shall be protected as instructed in accordance with the magnitude of the loss or harm that could result from inadvertent or deliberate disclosure, alteration, or destruction of the data. This language also applies to all subcontractors that are performing under this contract.

5.5.5 Documentation: For projects, the Contractor (and/or any subcontractor) shall produce documentation required to support software engineering activities over the entire development and operational life cycles in accordance with the HHS EPLC. The documentation includes, but is not limited to, specification (e.g., system requirements specification); design description (e.g., schematics, drawing); implementation artifacts (e.g., source code, programming logic, executables); instructions for use (e.g., users’ manuals, operating procedures; test documentation (e.g., documentation describing plans for, or results of, the system or component under test including test case specifications, test incident reports, test logs, test procedures, test reports); training materials and equipment; and other items that characterize, classify, or represent the system or some aspects thereof. The Contractor shall use provided templates, policies, forms and other agency documents as appropriate. Reference also Sub-Task 10.2, Other Documentation.

5.6 Project Management Support

5.6.1 Agile Project Management at an Enterprise Scale: The Contractor shall provide Agile project management support services that enable the effective management of IHS health IT related projects according to widely accepted Agile Project Management principles and methods. This task includes but is not limited to project communications management, project scheduling, project budgeting, product, release, and iteration backlog management and reporting, scrum meeting management, and project communications management. “At scale” means that the contractor must integrated enterprise governance requirements as specified in the HHS EPLC. These governance areas include the integration of portfolio management, CPIC, enterprise architecture, security, privacy, accessibility (Section 508 and Web Content Accessibility Guidelines (WCAG) 2.0 level AA), records management, etc. using Agile approaches and principles.

5.6.2 Release and Iteration Planning and Management: The Contractor shall develop, document, achieve buy-in and repeatable/reproducible iteration and release management plans. These plans should be easily understood by all impacted stakeholders, including product owners, technical stakeholder groups, and executives. It shall be the responsibility of the Contractor to integrate its own software development teams. However, the Contractor will also be required to integrate modules from the open source community, development teams, and other stakeholders. Iteration and release plans must take these dependencies into account.

5.6.3 Retrospective Management: The Contractor shall conduct Retrospective reviews in a manner to inspect itself and create a plan for improvements to be enacted during the next Sprint. The contractor shall identify and order the major items that went well and areas where potential improvements are needed and create a plan for implementing improvements for team management. These “lessons learned” and “corrective action plans” should be tracked and managed in order to realize the benefits of continuous process improvement.

5.6.4 Product Backlog Management: The product backlog shall be managed to contain a high-level view of all the work that must be completed to create the defined product. The product backlog shall rank the user stories and provide sufficient detail for decomposition and sprint cycle planning. The product backlog will also be a tool to support program budget planning and executive communications requirements.

5.6.5 Sprint Backlog Management: The sprint backlog shall list the tasks and requirements to be completed within a sprint. The sprint backlog shall include: user stories within the sprint in order of priority, tasks necessary to develop each user story, and effort, in hours, to complete each task. A “burndown chart” shall be provided that identifies the status of the work the development team has completed.

5.7 Analysis and Design

5.7.1 Requirements Definition and Management: The contractor shall perform Agile requirements definition and management (RDM) services to support product development. The requirements and features shall be captured and defined for the product backlog to sufficiently transition the non/functional and functional details into a planning cycle for a development sprint. The end goal being details (e.g., user stories, architecture stories, visualizations, models, functional requirements, usability performance requirements) that are prioritized and aligned to complete each defined respective sprint cycle. In some cases, documents that need to be created to pass certain organizational milestones, such as HHS EPLC stage gates or product certification, will be required and shall be included the requirements backlog. The Contractor shall coordinate with the respective government product owners (generally a medical informaticist) in carrying out this task. The Contractor shall also coordinate through the respective product owners to conduct user research and requirements analysis with professional specialty groups (e.g., user groups) and field stakeholders.

5.7.2 Design: Prior to development, a decomposition process by which the product backlog items are communicated and refined shall be conducted in collaboration with the assigned OIT personnel and the development team(s). The product development process shall be driven to a large extent by the quality and clarity of requirements process. The contractor shall perform product design using a range design practices (e.g., from high-level architectural modeling, iteration modeling, database refactoring, end user engagement (formative usability testing), continuous regression testing practices to low-level programming test practices).

5.7.3 Programming: Programming language shall be specified as a requirement and coding managed in development sprints. Sprints shall be managed and their sprint backlogs consistently maintained. The final deliverable for any software development task (including maintenance tasks) shall include:

A. Compiled software code

B. Source code for all applicable software

C. All required documentation (Installation, Technical, and User manuals see Sub-Task 5.10.2)

5.7.4 Trade Study/Trade-off Study Support

The Contractor shall conduct trade-off study services to support System/Product Design through activities performed by a multidisciplinary team to identify the most balanced technical solutions among a set of proposed viable solutions.

Trade-off studies and services shall be provided for services such as application design, user-centered research and design, requirements research and analysis, business process analysis, workflow design, task flow analysis, data architecture, database design, and systems design.

Trade-off studies shall also be conducted in support of major architectural decisions, generally accepted engineering decision-support techniques.

5.8 Testing

The Contractor shall provide services including module test planning, module accessibility testing (both Section 508 and WCAG 2.0, level AA), module performance and load testing, module unit testing, module integration testing, module regression testing, module standards conformance testing, formative usability testing (remote and mobile lab), meaningful use and industry certification testing support, Alpha/Beta testing support, and test results reporting. The Contractor shall work collaboratively with other Contractors to support integration testing, Alpha testing, and Beta testing. The Contractor shall be responsible for ensuring compliance with the published integration, Alpha, and Beta testing schedules. The Contractor shall also coordinate with the respective product owners during all testing activities. The Contractor shall ensure that program, project, and executive leaders always have a situational awareness of the user acceptance level of their respective products.

5.9 Implementation and Deployment Support

The Contractor shall provide technical support during implementation and deployments.