W81XWH-21-R-0023.docx
DOCX document 128 KB Posted
- Solicitation number
- W81XWH-21-R-0023
- Issued by
-
Department of the Army Medical Command
About this file
This is a request for proposal (RFP) for eCTD software license, maintenance, technical support services, and training. The Department of the Army Medical Command at Fort Detrick is seeking offers for 12 eCTD publishing user licenses, 50 reviewing user licenses, software maintenance, technical support, training, and consulting services. Proposals are due by 12:00 PM ET on March 6, 2021. Offerors must demonstrate their software can interface with OpenText Content Server 10.5, support Windows 2012 R2, and meet FDA 21 CFR Part 11 requirements. The contract will have a one-year base period and four one-year options, with pricing required for the base and option periods. The RFP includes instructions for proposal submission and evaluation criteria, with the non-price factors being more important than price. Technical approach, experience, management approach, and past performance will be evaluated.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| W81XWH-21-R-0023 Revised.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
W81XWH21R0023
Section SF 1449 - CONTINUATION SHEET
PERFORMANCE WORK STATEMENT
Performance Work Statement (PWS)
Agency/Activity: Enterprise Information Technology Project Management Office (eIT PMO)
Title: eCTD Software License, Maintenance, Technical Support Services, and Training for eCTD Publishing and Reviewing Software products and modules.
1.0 SCOPE / DESCRIPTION OF SERVICE
The eIT PMO needs to acquire software licenses and maintenance for (12) eCTD Publisher user accounts and up to (50) named eCTD reviewer accounts. Additional services required are Technical support services for resolving application problems, training services for both the eCTD publishing and reviewing users, FDA Validated software installation support and scripts, and consulting services to support regulatory questions by the eCTD publishing.
The eCTD software shall be capable of interfacing with OpenText Content Server 10.5 and current releases. The eCTD software must support Microsoft Windows 2012 R2 (64-bit) operating system and newer. This is a designated go, no-go requirement under RFP Technical Approach.
The eCTD software shall also meet U.S. Food & Drug Administration (FDA) 21 CFR Part 11 requirements. This is a designated go, no-go requirement under RFP Technical Approach.
The eCTD Software shall be able to be installed on premise and in the cloud. This is a designated go, no-go requirement under the RFP Technical Approach.
The eCTD system will be managed and maintained by the USAMRDC eIT PMO.
The technical support services must include supporting the migration of existing eCTD submissions and their full lifecycles from the existing eCTD publishing system. This software is also part of a suite of FDA compliant products maintained by the eIT PMO.
The eCTD software must be able to be installed and configured in accordance with cybersecurity best practices in order to reside on the DoD network. The vendor providing the software license and maintenance must support the government with any technical application modifications to ensure the government can receive a Risk Management Framework (RMF) Authority to Operate (ATO).
Directive: FDA compliant software products used for clinical trial research must support the stringent security controls and compliance with U.S. Food & Drug Administration (FDA) 21 CFR Part 11 electronic records and signature requirements.
2.0 TASKS
2.1 Task Management
The Contractor shall provide sufficient management to ensure that this task is performed efficiently, accurately, on time, and in compliance with the requirements of this document. Specifically, the Contractor shall designate a program manager to oversee this task and supervise staff assigned to this task. The Contractor shall ensure that a Monthly Progress Report is submitted outlining the expenditures, billings, progress, status, and any problems/ issues encountered in the performance of this task.
2.1.1 Monthly Progress Report (MPR) – Deliverable 2
The Contractor shall ensure that a MPR (Deliverable 2) is submitted outlining the expenditures, billings, progress, status, and any problems/ issues encountered in the performance of this task. Initial MPR is due NLT 45 days after contract award and NLT the 15th of each month thereafter.
The MPR shall include the labor hours expended, by labor category, for each task and sub-task.
The MPR shall provide status on any communications support provided by the Contractor, to include, but not limited to press releases, inputs to the J-9’s Significant Events report.
The MPR shall include information to update MRDC’s Organization Charts for the Contractor and its subcontractors. This will require coordination with the contractor, who is responsible for producing and updating the official MRDC organizational chart.
Burn rates and total charges for labor and other direct costs (ODC’s) need to be included in the MPR and reflect any additional charges that affect the total amount invoiced, such as fringe benefits, overhead and General and Administrative (G&A) charges.
The Contractor shall require all subcontractors to provide input to the MPR where there are critical or significant tasks related to the prime contract. Critical or significant tasks shall be defined by mutual agreement between the Government and Contractor.
2.1.2 Subcontractor Expenditures Plan – Deliverable 3
The Contractor shall prepare and deliver a Subcontract Expenditures Report (Deliverable 3) that discloses actual subcontract expenditures by company name, business size standard (i.e. Woman Owned Business, Veteran Owned Business, etc.), and other socioeconomic programs (i.e. Indian Incentive Program, Historically Black Colleges and Universities and Minority Institutions, etc.).
2.1.3 Management Plan – Deliverable 4
The Contractor shall develop a Management Plan (Deliverable 4) that shall require Government approval. It will be used to manage, track and evaluate the Contractor’s performance. The Management Plan shall consist of control policies and procedures in accordance with standard industry practices for project administration, execution and tracking. A draft Management Plan will be submitted with offeror’s proposal.
The Management Plan shall include the following:
· Identification of milestones where Government information/activity is required and timeline dependencies for subsequent Contractor activities;
· An Integrated Master Management Plan (IMMP) describing the Contractor’s overall management approaches, policies and procedures including suggested project metrics; and,
· A detailed staffing plan.
The final Management Plan shall be due five (5) calendar days after the start of the contract and updated as required.
2.1.4 Quality Control Plan – Deliverable 5
The Contractor shall prepare and adhere to a Quality Control Plan (QCP). A QCP will initially be submitted NLT 30 DACA (Deliverable 5). The QCP shall document how the Contractor will meet and comply with the quality standards established in this statement of work. At a minimum, the QCP must include a self-inspection plan, an internal staffing plan, and an outline of the procedures that the Contractor will use to maintain quality, timeliness, responsiveness, and customer satisfaction. After acceptance of the quality control plan the contractor shall receive the contracting officer’s acceptance in writing of any proposed change to their QCP system. This plan must be specific to the requirement as outlined.
2.1.5 Contingency Operations Plan – Deliverable 6
The Contractor shall prepare and submit a Contingency Operations Plan (COP) to the Government. The COP shall be due ten (10) calendar days after the award of the contract, and shall be updated on a quarterly basis (Deliverable 6). The COP shall document Contractor’s plans and procedures to maintain eIT PMO support during an emergency. The Contingency Operations Plan shall include the following:
· A description of the Contractor’s emergency management procedures and policy
· A description of how the Contractor will account for their employees during an emergency
· Planned temporary work locations or alternate facilities
· How the Contractor will communicate with eIT PMO during emergencies
· A list of primary and alternate Contractor points of contact, each with primary and alternate:
· Telephone numbers
· E-mail addresses
· Procedures for protecting Government furnished equipment (if any)
· Procedures for safeguarding sensitive and/or classified Government information (if applicable)
2.1.6 Operations During Emergency Situations
Individual contingency operation plans shall be activated immediately after determining that an emergency has occurred, shall be operational within twelve (12) hours of activation, and shall be sustainable until the emergency situation is resolved and normal conditions are restored or the contract is terminated, whichever comes first. In case of a life threatening emergency, the COR will immediately make contact with the Contractor Task Managers to ascertain the status of any Contractor personnel who were located in Government controlled space affected by the emergency. When any disruption of normal, daily operations occur, the Contractor Task Manager shall promptly open an effective means of communication with the COR and verify:
· Key points of contact (Government and Contractor)
· Temporary work locations (alternate office spaces, telework, virtual offices, etc.)
· Means of communication available under the circumstances (e.g. email, webmail, telephone, FAX, courier, etc.)
· Essential work products expected to continue production by priority
The Contractor Task Manager, in coordination with the COR, shall make use of the resources and tools available to continue eIT PMO contracted functions to the maximum extent possible under emergency circumstances. Regardless of contract type, and of work location, Contractors performing work in support of authorized tasks within the scope of their contract shall charge those hours accurately in accordance with the terms of this contract.
2.1.7 Identification of Contractor Personnel: All contract personnel attending meetings, answering Government telephones, and working in other situations where their contractor status is not obvious to third parties are required to identify themselves as such to avoid creating an impression in the minds of members of the public that they are Government officials. They must also ensure that all documents or reports produced by contractors are suitably marked as contractor products or that contractor participation is appropriately disclosed. All contractor personnel will be required to obtain and wear badges in the performance of this service.
2.1.8 Contracting Officer Representative (COR): The COR will be identified by separate letter. The COR monitors all technical aspects of the contract and assists in contract administration. The COR is authorized to perform the following functions in addition to what is outlined in the designation letter: assure that the Contractor performs the technical requirements of the contract: perform inspections necessary in connection with contract performance: maintain written and oral communications with the Contractor concerning technical aspects of the contract: issue written interpretations of technical requirements, including Government drawings, designs, specifications: monitor Contractor's performance and notifies both the Contracting Officer and Contractor of any deficiencies; coordinate availability of Government furnished property, and provide site entry of Contractor personnel. A letter of designation will be issued to the COR and a copy of which is sent to the Contractor, stating the responsibilities and limitations of the COR, especially with regard to changes in cost or price, estimates or changes in delivery dates. The COR is not authorized to change any of the terms and conditions of the resulting order.
2.2 Specific Tasks
Task 1: Software Maintenance (FFP) The contractor shall provide software licenses and maintenance for the number of licenses listed below:
(12) eCTD Publishing User Licenses
(50) eCTD Reviewing User Licenses (concurrent users)
Licensing shall also include:
· The ability to perform linking within the publishing application
· The ability to do submission validation
· Validation Test scripts for the initial version and future versions of both eCTD Publishing software and eCTD Reviewing software.
The contractor shall provide a cost to add licenses over the course of the contract, (see Task 5). The increase during each POP shall not exceed 5 Publishing user Licenses and 15 Viewing licenses in a contract year. This is to allow for flexibility should the end user base increase. Software license maintenance must maintain the following functions:
1. eCTD Publishing
1. eCTD Submission Validation
1. eCTD Viewing (See PWS Attachment A for a full list of software system requirements)
(See Attachment B for the Quality Assurance and Surveillance Plan (QASP) for maintenance requirements)
Task 2: Consulting and Technical Support Services (Reimbursable) Consulting and Technical Support services requested shall include:
Standard eCTD Software Project Management:
The contractor shall work collaboratively with the eIT PMO staff on remediation of network security vulnerabilities discovered during evaluation testing in order to achieve a secure software installation which is required to maintain the software on a DoD network. The contractor shall provide necessary support and communication to schedule and provide all services.
Technical and Regulatory Consulting:
The contractor shall provide technical support for installation, upgrade, and validation support for all software maintained under this contract on an as needed basis. Technical support services are required for but not limited to:
1. Project Management
1. Regulatory Consulting
1. Installation of eCTD software products
1. Pre-installation and installation testing
1. Validation support- scripts included
1. eCTD Software Upgrade Support
Installation, Testing, Configuration, Migration, Validation, etc.:
The contractor shall work collaboratively with eIT PMO staff on the installation, configuration, upgrades and data migration of eCTD software products, modules, and data into two computing environments (test and production) in a datacenter or in a cloud environment. This will include the development/modification of installation instructions to allow the products to function within the parameters specified for Department of Defense installations.
The contractor shall provide technical support and documentation for testing and validation of the products. Documents to be generated, authored/updated, and provided shall include the following on an as needed basis:
0. Master Validation Plan (MVP)
0. Design Specifications
0. Validation Test Plan for Installation Qualification (IQ) based on vendor provided templates
0. Validation source book for Installation Qualification (IQ)/Operational Qualification (OQ)/Performance Qualification (PQ)
0. Modification of standard IQ test scripts for eIT PMO installation
0. System Configuration guide
0. Work instructions and process flow
0. Documents should be provided in Microsoft Word format and be updated for the software version being supported.
Task 3: Training (Reimbursable) Request a menu of trainings available to successfully train and support end users for the following software products.
· eCTD Publisher
· eCTD Reviewer The contractor shall provide live onsite or virtual training and training documentation to eIT PMO product administrators, advanced users and general users to support all products and modules delivered under this PWS. The contractor shall provide a list of training available with costs and cost of all training materials. Training courses shall include but may not be limited to:
Standard eCTD Publisher Training
Advanced eCTD Publisher Training
Administrator Training eCTD Reviewer Training
Training materials shipping expense (if required)
See PWS Section 5 (Training ODCs)
Task 4: Travel (Reimbursable) Travel cost estimate for in-person trainings or for technical consulting support held at Fort Detrick to fully support end users and administrators. See PWS Section 5 (Travel ODCs)
Task 5: Option for increased quantities of software licenses, training and travel required over the life of the contract
IAW FAR Clause 52.217-6, the contractor shall provide preset pricing for additional new SW Licenses & Maintenance and for training, as required, over the life of the contract. The estimated number of each new license or support that may be required each year are unknown and will modified into this contract as required. There are no optional CLINS for this at time of award, but there is a great potential for increase quantities during the life of this contract.
3.0 DELIVERABLES
3.1 Delivery Address
All deliverables shall be submitted to the COR designated in the COR appointment letter and as directed by the COR upon award of the contract.
3.2 Method of Delivery
Electronic copies shall be delivered using Microsoft Office suite of tools (for example, MS WORD, MS EXCEL, MS POWERPOINT, MS PROJECT, or MS ACCESS format), unless otherwise specified by the COR. Electronic submission shall be made via email, unless otherwise agreed to by the COR.
3.3 Shipping
The Contractor shall use the U.S. Postal Service standard delivery for delivery of materials, equipment, or required hardcopy documents. The COR must approve all exceptions to this requirement.
3.4 Government Acceptance Period
The COR will have ten (10) workdays to review draft deliverables and make comments. The Contractor shall have five (5) workdays to make corrections. Upon receipt of the final deliverables, the COR will have two (2) workdays for final review prior to acceptance or providing documented reasons for non-acceptance. Should the Government fail to complete the review within the review period the deliverable will become acceptable by default, unless prior to the expiration of the ten (10) work days the Government notifies the Contractor in writing to the contrary. The final submission should be deemed approved if the Government has not rejected it in 30 days.
The COR will have the right to reject or require correction of any deficiencies found in the deliverables that are contrary to the information contained in the Contractor’s accepted proposal. In the event of a rejected deliverable, the Contractor will be notified in writing by the COR of the specific reasons for rejection. The Contractor shall have five (5) workdays to correct the rejected deliverable and return it per delivery instructions.
3.5 Delivery Schedule Abbreviations
The following abbreviations are used in the delivery/deliverable schedule:
| Abbreviation |
| Definition |
| COR |
| Contracting Officer's Representative for the Task order |
| CS |
| Contract Specialist |
| DA |
| Days after |
| DACA |
| Days after contract award (award of this order) |
| DAEOM |
| Days after end of month |
| Days |
| Calendar Days unless otherwise specified |
| E |
| Electronic Copy |
| H |
| Hard Copy |
| NLT |
| No Later Than |
| PWS Ref |
| Performance Work Statement Reference (paragraph number) |
3.6 Deliverable/Delivery Schedule
A summary of deliverables follows. Copies are to be provided to the Government officials electronically.
(This technical exhibit lists any reports or documentation that is required as a deliverable to include the frequency, # of copies, medium/format and who/where it is to be submitted. A deliverable is anything that can be physically delivered but may include non-physical things such as meeting minutes. Note: All PWS deliverables should be included in this exhibit.)
| Item |
| PWS Ref |
| Title |
| Dist |
| Initial |
| Subsequent |
| Deliverable 1 |
| PWS Attachment B |
| Non-Disclosure Agreement |
| COR |
| Signed statements are due, from each employee assigned, prior to performing ANY work on this task. |
| Deliverable 2 |
| 2.1.1 |
| Monthly Progress Report |
| COR |
| NLT 45 DACA |
| NLT 15th of each month |
| Deliverable 3 |
| 2.1.2 |
| Subcontract Expenditures Report |
| CS |
COR
| NLT 90 DACA |
| Quarterly thereafter. A final submission reflecting all expenditures on this order is due within 5 days of completion of the order. |
| Deliverable 4 |
| 2.1.3 |
| Management Plan |
| COR |
| Draft with proposal. Final NLT 5 DACA |
| Updated as required |
| Deliverable 5 |
| 2.1.4 |
| Quality Control Plan |
| COR |
| Initial NLT 30 DACA. Final NLT 45 DACA |
| Updated as required |
| Deliverable 6 |
| 2.1.5 |
| Contingency Operations Plan |
| COR |
| NLT 10 DACA |
| Updated quarterly |
4.0 CONTRACT ADMINISTRATION DATA
4.0.1 Recognized Holidays: Contractor is not required to perform services on the below Federal holidays.
| New Year’s Day | Labor Day | ||
| Martin Luther King Jr.’s Birthday | Columbus Day | ||
| President’s Day | Veteran’s Day | ||
| Memorial Day | Thanksgiving Day | ||
| Independence Day | Christmas Day |
4.0.2 Hours of Operation:
The contractor is responsible for coverage conducting business, between the hours of 08:00 am through 05:00 pm EST, Monday thru Friday except Federal holidays or when the Government facility is closed due to local or national emergencies, administrative closings, or similar Government directed facility closings. For other than firm fixed price contracts, the contractor will not be reimbursed when the government facility is closed for the above reasons. The Contractor must at all times maintain an adequate workforce for the uninterrupted performance of all tasks defined within this PWS when the Government facility is not closed for the above reasons. When hiring personnel, the Contractor shall keep in mind that the stability and continuity of the workforce are essential.
Some core labor coverage may contain some variant agreed upon at the kick-off meeting. Some mission requirements may require work before or after established core hours. Weekend and Federal holiday on-call coverage may be required. Official travel may require travel during hours and days outside of the norm e.g. long-distance CONUS or OCONUS travel in order to accommodate customer assist visit schedules agreed upon by DVBIC.
4.0.3 Security Requirements:
Contractor personnel performing work shall follow the MRDC personnel security policy for gaining clearances and common access cards.
4.045 Physical Security:
The contractor shall be responsible for safeguarding all government equipment, information and property if/when provided for contractor use. At the close of each work period, government facilities, equipment, and materials shall be secured.
4.0.5 Key Control:
The Contractor shall establish and implement methods of making sure all keys/key cards issued (if required) to the Contractor by the Government are not lost or misplaced and are not used by unauthorized persons. NOTE: All references to keys include key cards. No keys issued to the Contractor by the Government shall be duplicated. The Contractor shall develop procedures covering key control that shall be included in the Quality Control Plan. Such procedures shall include turn-in of any issued keys by personnel who no longer require access to locked areas. The Contractor shall immediately report any occurrences of lost or duplicate keys/key cards to the COR.
5.0 Place of Performance:
The Contractor shall perform the primary (SW) services at Fort Detrick, MD with reachback support from the Contractor’s facility. The Government will provide access to Government controlled facilities, equipment, and materials for daily business use of staff called for under this order if required. The Contractor will be provided keys or codes for access to the Government facility if required. These keys and codes shall be controlled, tracked, and protected. Upon termination of the period of performance, all keys and/or access badges provided by the Government for the Government facility shall be turned in to the COR.
5.1 Other Direct Costs (ODCs)
The Government intends to utlize “Plugged” Not-to-Exceed (NTE) amount for all ODCs listed below.
5.1.2 Travel ODCs
The Government intends to utilize a “Plugged” Not-to-Exceed (NTE) amount for all ODCs (to include Travel – See ODC Matrix Below). This plugged value is inclusive of all items outlined in PWS Section 2.2 (Task 4 – Training and Consulting Support Services).
ODC Matrix: Base Period & All Option Periods
| Contract Period | Travel ODC Plugged Values |
| Base Period | $10,000.00 |
| Option Period 1 (OP1) | $2,500.00 |
| Option Period 2 (OP2) | $2,500.00 |
| Option Period 3 (OP3) | $10,000.00 |
| Option Period 4 (OP4) | $2,500.00 |
Arrangements for and costs of all travel, transportation, meals, lodging, and incidentals are the responsibility of the Contractor. Travel costs shall be incurred and billed in accordance with FAR Part 31. Costs for these expenses will be reviewed, certified and approved by the COR. All travel and transportation shall utilize commercial sources and carriers provided the method used for the appropriate geographical area results in reasonable charges to the government. The Government will not pay for business class or first-class travel. Lodging and meals shall be reimbursed in accordance with regulations defined in FAR PART 31.
5.1.3 Travel Outside of the U.S.
Not applicable to this task.
5.1.4 Training ODCs
The Government intends to utilize a “Plugged” Not-to-Exceed (NTE) amount for all Training ODCs – See ODC Matrix Below. This plugged value is inclusive of all items outlined in PWS Section 2.2 (Task 3 – Training Services).
ODC Matrix: Base Period & All Option Periods
| Contract Period | Travel ODC Plugged Values |
| Base Period | $20,000.00 |
| Option Period 1 (OP1) | $10,000.00 |
| Option Period 2 (OP2) | $10,000.00 |
| Option Period 3 (OP3) | $20,000.00 |
| Option Period 4 (OP4) | $10,000.00 |
The Government will request training based on frequency and need and will coordinate with the Contractor when training requirements are requried. Basic training requirements are outlined in PWS Section 2.2 (Task 3) and the contractor is required to provide basic training pricing (if not seperately priced elsewhere) and these prices will be utilized to request and fund training as required throughout the life of this contract.
6.0 OTHER TERMS, CONDITIONS, AND PROVISIONS
6.1 Non-Disclosure Agreement – Deliverable 1
The Contractor shall ensure that the Non-Disclosure Agreement (Attachment B to PWS) (Deliverable 1) is signed by all staff assigned to or performing on this Task order before performing any work, including all subcontractors and consultants. The Non-Disclosure Agreement shall be cosigned by a corporate official (Contractor Task Manager or higher). The Contractor shall also ensure that all staff understand and adhere to the terms of the non-disclosure statement, protecting the procurement sensitive information of the Government and the proprietary information of other Contractors. Assignment of staff who have not executed this statement or failure to adhere to this statement shall constitute default on the part of the Contractor. All Non-Disclosure Agreements shall be submitted NLT 30 days after award of this task order.
6.2 Service Contract Reporting
Service Contract Reporting (SCR) has replaced Contractor Manpower Reporting (CMR) Requirement. Service contractor reporting of information is required in the System for Award Management (SAM) for:
• Contract Awards, no IDVs
• Contract Awards include purchase orders, delivery/task orders, BPA calls, and definitive contracts
• Service Contracts, i.e. any PSC that starts with a letter excluding utility PSCs (S110, S111, S112, S114, and S119)
• All cost-reimbursement, time-and-materials, and labor-hour service contracts with an estimated total value > $150,000 and base date signed is between 10/1/13 and 9/30/18.
• Fixed Price Contracts: If the contract's base date signed AND base effective date is between 10/01/2013-09/30/2014, the total contract value must be >= $2.5M
• Fixed Price Contracts: If the contract's base date signed AND base effective date is between 10/01/2014-09/30/2015, the total contract value must be >= $1M
• Fixed Price Contracts: If the contract's base date signed AND base effective date is between 10/01/2015-09/30/2018, the total contract value must be >= $500,000
Steps for Submitting a Service Contract Report (SCR)
1. Go to www.sam.gov and log in.
2. Select Entity Registrations and then select Service Contract Reporting.
3. SAM displays your entities which have service contracts and meet the reporting criteria. Select View by entity to see the service contracts for each entity.
4. Next, select Add for the service contract against which you want to create a Service Contract Report. Each service contract which meets the FAR Subpart 4.1703 reporting thresholds is displayed.
5. You will be taken to the Complete Service Contract Report page. SAM displays the contract details and allows you to report. You are required to enter the following information:
• Total Amount Invoiced: Total dollar amount invoiced for services performed during the previous Government fiscal year under the contract (this amount should include the prime and any subcontract amount).
• Prime Contractor Hours Expended: Prime contractor direct labor hours expended on the services performed during the previous Government fiscal year. The amount you enter is automatically divided by 2,080 hours to calculate a Full Time Employee (FTE) equivalent, displayed under the Prime Contractor Hours Expended as Prime Contractor FTEs.
6. Report any required Tier 1 subcontractor information by selecting the Add Tier 1 Subcontract Information button.
7. When you are ready to submit the report, select Submit. This saves your report and returns you to the Select Service Contract page where you can create other SCRs or edit an existing SCR.
6.3 Contractor Employees
Attendance at Meetings
Post Award Conference/Periodic Progress Meetings: The Contractor agrees to attend any post award conference convened by the contracting activity or contract administration office in accordance with Federal Acquisition Regulation Subpart 42.5. The contracting officer, Contracting Officers Representative (COR), and other Government personnel, as appropriate, may meet periodically with the contractor to review the contractor's performance. At these meetings the contracting officer will apprise the contractor of how the government views the contractor's performance and the contractor will apprise the Government of problems, if any, being experienced. Appropriate action shall be taken to resolve outstanding issues. These meetings shall be at no additional cost to the government.
Contractor personnel may be required to attend meetings or otherwise communicate with Government and/or other contract representatives to meet the requirements of this order. Contractor personnel will make their Contractor status known during introductions.
Use of Military Rank by Contractor Personnel
Contractor personnel, while performing in a Contractor capacity, are prohibited from using their retired or reserve component military rank or title in all written or verbal communications associated with the contract under which they provide services.
6.4 Data Rights
The Government will retain rights to all data produced in the course of developing, deploying, training, using and supporting the eIT PMO.
The Government has unlimited rights to all documents/material produced under this contract. All documents and materials, to include the source codes of any software, produced under this contract shall be Government owned and are the property of the Government with all rights and privileges of ownership/copyright belonging exclusively to the Government. These documents and materials may not be used or sold by the contractor without written permission from the Contracting Officer. All materials supplied to the Government shall be the sole property of the Government and may not be used for any other purpose. This right does not abrogate any other Government rights.
6.5 Quality Assurance
The Government will review Monthly Progress Reports and will attend regular task performance review meetings with the Contractor to survey quality of products and services. The government shall evaluate the contractor’s performance under this contract in accordance with the Quality Assurance Surveillance Plan. This plan is primarily focused on what the Government must do to ensure that the contractor has performed in accordance with the performance standards. It defines how the performance standards will be applied, the frequency of surveillance, and the minimum acceptable defect rate(s).
6.5.1 Quality Assurance Surveillance Plan (QASP)
The Government intends to utilize a Quality Assurance Surveillance Plan (QASP) to monitor the quality of the Contractor’s performance. The oversight provided for in the order and in the QASP will help to ensure that service levels reach and maintain the required levels throughout the contract term. Further, the QASP provides the COR with a proactive way to avoid unacceptable or deficient performance, and provides verifiable input for the required Past Performance Information Assessments. The QASP will be finalized immediately following award and a copy provided to the Contractor after award. The QASP is a living document and may be updated by the Government as necessary.
6.5.2 Performance Requirements Summary Matrix
By monitoring the Contractor, the COR will determine whether the performance levels set forth in the order have been attained. Performance standards are specified in the following Performance Requirements Summary Matrix in the Standard and Acceptable Quality Level columns.
eCTD Software Standard Level for Software Maintenance (Times are Eastern Time/ET)
Standard Level for Support Services
| Task |
| Indicator |
| Standard |
| Acceptable Quality Level |
| Method of Surveillance |
Task 2.
Work collaboratively with eIT PMO staff to successfully upgrade and validate the software. This will include the development /modification of installation instructions to allow the products to function within the parameters specified for Department of Defense Installation.
Project management/technical consulting/regulatory consulting services are provided as requested by eIT PMO Software implemented on DoD servers in accordance with all current DOD requirements.
Engagement. Technical or regulatory requests are provided through the project manager are addressed
| All security deficiencies have been remediated to the satisfaction of DoD security requirements Consulting engagements are provided and resolve the issue causing the consulting |
| Zero Software failures not mitigate. |
All installation performed successfully and all validation issues resolved Direct observation and 100% inspection
Task 3 Provide training and documentation to product administrators, advanced users, and general users to support all products and modules delivered under this contract.
| All users are trained commensurate with their role |
| Training delivered onsite or virtually, at a mutually agreed upon time |
| Training delivered close to production go-live date for end-users |
| 100% inspection |
PWS Attachment A
Software System Requirements
Overview The eCTD Publisher System is intended for use by USAMRDC eIT PMO customers/user base for preparation, and life cycle maintenance of electronic regulatory submissions originating from the Army Office of the Surgeon General (OTSG) sponsored investigational product development. The critical function of the system is the ability to generate electronic regulatory submissions. In addition, the system shall have the ability to automate workflow steps required to manage preparation of electronic submissions for submission to regulatory agencies (e.g. US FDA).
The eCTD publishing system shall be used for:
· Preparation and lifecycle maintenance of electronic regulatory submissions
· Greater efficiency within Regulatory Submissions
· A higher level of compliance with applicable regulations
The eCTD publishing system shall have the ability to:
· Scale the system to handle a larger number of submissions with increased complexity
· Provide seamless access to third parties (e.g. external regulatory reviewers, consultants, CRO’s, etc.)
· Integrate the eCTD publishing system with other key USAMRDC systems (e.g. Open Text – Content Server)
User Requirements:
The requirements listed in the tables below shall be accommodated by the vendor offering a complete eCTD Publishing System.
| FORMAL REQ/SPEC ID |
| FORMAL REQUIREMENTS/SPECIFICATIONS |
Electronic Common Technical Document (eCTD) Software
4.2 User & Software Requirement/Specification Categories
4.2.1 Submission Assembly Category
| SA 1.0 |
| The SYSTEM shall support the publishing of all types of reports: IND, Briefing package, CTA, Annual Report,, Information Amendment (safety, efficacy, non-clinical), Annual Reports (IND & NDA), Drug Master File, Clinical Study Reports (legacy format), SAS Transport Files, FDAMA, ISS (Integrated Safety Summary). |
| SA 2.0 |
| The SYSTEM shall be capable of producing any specified submission type that includes: CTD, eCTD, IND, NDA, and BLA. |
| SA 3.0 |
| The SYSTEM shall allow paper and electronic publishing properties/settings to be managed at the submission level and modified at component level. |
| SA 4.0 |
| The SYSTEM shall provide the ability for the user to manage paper and electronic submission publishing from the same tool, interface and assembly. |
| SA 5.0 |
| The SYSTEM shall contain reusable submission structure templates that can be used to create a submission instance. |
| SA 7.0 |
| The SYSTEM shall allow users to enter/alter metadata manually. |
| SA 8.0 |
| The SYSTEM shall have the ability to attach leaf files to submission/publication structure when a mass drag and drop is performed from the document repository. |
| SA 9.0 |
| The SYSTEM shall allow multiple users to assign documents to the same submission/publication structure at the same time. |
| SA 13.0 |
| The SYSTEM shall provide the ability to lock all or part of a submission structure when complete. |
| SA 14.0 |
| The SYSTEM shall provide the ability to set security such that the eCTD submission cannot be unintentionally or inappropriately manipulated. |
| SA 15.0 |
| The SYSTEM shall provide the ability to determine if a leaf element contains child elements. |
| SA 16.0 |
| The SYSTEM shall provide the ability to lock folders, assemblies, and volume ranges (for paper submissions). |
| SA 17.0 |
| The SYSTEM shall allow for the use of multiple document types. |
| SA 18.0 |
| The SYSTEM shall provide the ability to populate submission attributes from documents located in the Document Repository. |
| SA 19.0 |
| The SYSTEM shall provide a visual indicator showing when a submission element does not have content assigned. |
| SA 20.0 |
| The SYSTEM shall provide a visual indicator showing when a submission element has a specific version of a document bound to it and a later version of the document exists in the document repository. |
| SA 21.0 |
| The SYSTEM shall allow users to update the outline structure when a source document is changed in the document repository. |
| SA 23.0 |
| The SYSTEM shall allow existing components within the hierarchical structure of the submission or publication to be promoted and demoted. |
| SA 24.0 |
| The SYSTEM shall allow users to modify attributes of files after added to the submission assembly. |
| SA 25.0 |
| The SYSTEM shall provide the ability to view the content of a document during the assembly process. |
| SA 26.0 |
| The SYSTEM shall provide the ability to specify whether PDF rendered hyperlinks are displayed as thin black lines around hyperlinked text or as blue text. |
| SA 29.0 |
| The SYSTEM shall support intra-document linking by using relative paths. |
| SA 30.0 |
| The SYSTEM shall support the ability to create multiple links to items that occur on different pages. |
| SA 31.0 |
| The SYSTEM shall provide the ability to create hyperlinks within text and tables to referenced content within the submission assembly. |
| SA 36.0 |
| The SYSTEM shall provide the ability for a user to exclude documents from the published output. |
| SA 37.0 |
| The SYSTEM shall allow the insertion of placeholders for documents that have not yet been created |
4.2.2 Opentext Content Server 10.5 (EDMS) Integration Category
| LL 1.0 |
| The SYSTEM shall integrate with Opentext Content Server to pull documents into a submission assembly. |
| LL2.0 |
| The SYSTEM shall pull specific metadata from the document repository. (e.g., study tagging files) |
| LL 3.0 |
| The SYSTEM shall pull attributes associated to a leaf when attached to submission assembly. |
| LL 4.0 |
| The SYSTEM shall support the ability to specify the cabinet/folder location of the published output in the document repository. |
| LL 5.0 |
| The SYSTEM shall allow the assignment of the latest or current version of a document to a structural element that has been imported from Opentext Content Server. |
| LL 6.0 |
| The SYSTEM shall allow users to refresh the submission/publication outline to reflect updated document properties when the files are stored in Opentext Content Server. |
4.2.3 Submission Publishing (eCTD) Category
| SP 1.0 |
| The SYSTEM shall supply the submission templates for the following standards: ICH eCTD specification 3.2, FDA M1 specifications, FDA Study Tagging File 2.2, EMEA M1 specification, JP M1 specification, Canada M1 specification, Swiss M1 specification |
| SP 2.0 |
| The SYSTEM vendor SHALL provide updates to any portion of the software to include the Document Type Definitions (DTDs) as needed. |
| SP 3.0 |
| The SYSTEM shall process Structured Product Labeling (SPL) files. |
| SP 4.0 |
| The SYSTEM shall allow for the publishing of Structured Product Labeling (SPL) in native XML file format or in PDF. |
| SP 6.0 |
| The SYSTEM shall be able to create Study Tagging Files according to ICH / US / FDA Specification. |
| SP 7.0 |
| The SYSTEM shall allow creation of STFs for legacy study reports (not in CTD granularity). |
| SP 8.0 |
| The SYSTEM shall provide separate metadata fields for M4 and M5 study reports for Study ID and Study Title. |
| SP 10.0 |
| The SYSTEM shall allow multiple metadata to be inherited from the existing STF under the same leaf, when adding new studies to an existing leaf. |
| SP 11.0 |
| The SYSTEM shall provide automation to assist in managing studies in eCTD M4/5 that include: numbering, structure population, metadata, STF attributes. |
| SP 13.0 |
| The SYSTEM shall allow for the import of an eCTD that was created in another publishing system with all metadata and structure intact. |
| SP 14.0 |
| The SYSTEM shall allow for the import of legacy eCTD submissions generated with ICH specification 3.0. |
| SP 16.0 |
| The SYSTEM shall allow the import of all lifecycle operations correctly between sequences. |
| SP 17.0 |
| The SYSTEM shall lock/unlock all submissions once import is complete depending on selection made during import. |
| SP 18.0 |
| The SYSTEM shall be able to delete imported sequences/applications in case of errors/warnings. |
| SP 19.0 |
| The SYSTEM shall allow for the clone of an eCTD submission using an existing assembly. |
| SP 20.0 |
| The SYSTEM shall provide the ability to maintain links to documents included in the original submission structure when a submission structure is cloned to create a new submission. |
| SP 21.0 |
| The SYSTEM shall provide the ability to convert the case of letters to lower and avoid special characters except hyphens for only file names and folder names when creating the submission/published output. |
| SP 22.0 |
| To ensure that PDF files can be opened correctly by the FDA, the SYSTEM shall be able to optimize PDF files for fast web view during the compilation process. |
| SP 23.0 |
| The SYSTEM shall provide a bulk file upload process for all file types. |
| SP 24.0 |
| The SYSTEM shall have the ability to identify document field attributes as mandatory to support eCTD compilation. |
4.2.4 eCTD Validation Requirements Category
| VR 1.0 |
| The SYSTEM shall validate against all Document Type Definitions (DTDs) which include all region specific, ICH and STF. |
| VR 2.0 |
| The SYSTEM shall be able to validate module by module. |
| VR 3.0 |
| The SYSTEM shall have a mechanism to check that the required regional metadata of a submission is accurate and prompt with an error message if any information is missing. |
| VR 4.0 |
| The SYSTEM shall allow re-validation after changes in output occur. (i.e., manual linking, page swaps) |
| VR 5.0 |
| The SYSTEM shall verify all leaf elements have leaf IDs assigned to them. |
| VR 6.0 |
| The SYSTEM shall have the capability to create a report for a published submission sequence that identifies if any information is missing. |
| VR 7.0 |
| The SYSTEM shall have the ability to verify folder and file naming conventions per ICH recommendations to include, but not limited to, maximum length of the name of a single folder or file is 64 characters including the extension; written in lower case only; files should have one and only one file extension; file extension should be used to indicate the format of the file; document name is the first name in the file name. (Ex. - “docname” in the file name “docname.ext”) |
| VR 8.0 |
| The SYSTEM shall have the capability to calculate and verify MD5 checksum of documents that are part of a submission. |
| VR 9.0 |
| The SYSTEM shall check that all files referenced in the XML backbone exist in the appropriate submission folders. |
| VR 10.0 |
| The SYSTEM shall verify that all files in the submission folder are referenced in the XML backbone. |
| VR 12.0 |
| The SYSTEM shall check that the sequence number attribute is four (4) digits and validate that the sequence number defined in the regional xml matches the folder name. |
| VR 13.0 |
| The SYSTEM shall check that the application number is six (6) digits and validate the application number defined in the regional xml. |
| VR 14.0 |
| The SYSTEM shall check that the Stylesheet has been declared within the regional and index.xml files. |
| VR 15.0 |
| The SYSTEM shall check that the DTD has been declared within the regional and index xml files. |
| VR 16.0 |
| The SYSTEM shall include file-level checks for PDF requirements (e.g. V 1.4). |
| VR 17.0 |
| The SYSTEM shall check for hyperlink and bookmark correctness. |
| VR 18.0 |
| The SYSTEM shall provide the ability to validate Study Tagging Files. |
| VR 19.0 |
| The SYSTEM shall issue a warning message when the folder file path exceeds 230 characters. |
| VR 21.0 |
| The SYSTEM shall be capable of generating a validation report. |
4.2.5 Submission Publishing (Paper) Category
| SPP 1.0 |
| The SYSTEM shall provide the ability to generate published paper output as multiple volumes or a single volume file. |
| SPP 2.0 |
| The SYSTEM shall provide the ability to import eCTDs and create a paper format. |
| SPP 3.0 |
| The SYSTEM shall provide the ability to automatically create volumes in bulk based on page size for the entire dossier or for selected sections only. |
| SPP 3.1 |
| The SYSTEM shall provide the ability to manually add volumes and/or readjust them. |
| SPP 4.0 |
| The SYSTEM shall provide the ability for a user to specify volume breaks for a paper submission. |
| SPP 6.0 |
| The SYSTEM shall be able to generate published output that meets the FDA regulatory requirements for a paper CTD. (i.e., table of contents, volumes, tabs, slip sheets, cover pages) |
| SPP 7.0 |
| The SYSTEM shall allow the generation of a Table of Contents, Table of Tables, Table of Figures, Table of Listings and Table of Appendices to be placed anywhere within the submission structure. |
| SPP 8.0 |
| The SYSTEM shall allow the volume range of a Table of Contents, Table of Figures, Table of Tables, Table of Listings and Table of Appendices to be specified by the user. |
| SPP 10.0 |
| The publishing system must render a searchable published output. |
| SPP 11.0 |
| The SYSTEM shall provide the ability to render documents to PDF. |
| SPP 12.0 |
| The SYSTEM shall provide the ability for the user to specify if a file should not be rendered to PDF (i.e., use source document in native format). |
| SPP 15.0 |
| The SYSTEM shall provide the ability to create Bookmarks that are identical to the Table of Contents for paper submissions. |
| SPP 17.0 |
| The SYSTEM shall provide the ability to include symbols in Bookmarks. |
| SPP 18.0 |
| The SYSTEM shall support the use of symbols in all content during the rendering process. |
| SPP 19.0 |
| The SYSTEM shall support the ability to convert all source document cross-references into active hyperlinks within the PDF file. |
| SPP 20.0 |
| The SYSTEM shall be able to add cross-references and convert existing electronic hyperlinks to margin cross references for paper output. |
| SPP 21.0 |
| The SYSTEM shall provide the ability to apply a specified header or footer to a specific document included in the submission structure. |
| SPP 22.0 |
| The SYSTEM shall provide the ability to apply a specified header to the entire submission. |
| SPP 23.0 |
| The SYSTEM shall provide the ability to exclude a submission header from a specific document included in the submission structure. |
| SPP 24.0 |
| The SYSTEM shall provide the ability to apply a specified footer to a specific document or a set of documents included in the submission structure. |
| SPP 25.0 |
| The SYSTEM shall provide the ability to apply a specified footer to the entire submission. |
| SPP 26.0 |
| The SYSTEM shall provide the ability to exclude the submission footer from a specific document or a set of documents included in the submission structure. |
| SPP 27.0 |
| The SYSTEM shall provide the ability to include a specified cover sheet to appear before the document content. |
| SPP 28.0 |
| The SYSTEM shall provide the ability to insert tabs in the submission structure for paper submissions. |
| SPP 29.0 |
| The SYSTEM shall provide the ability for the user to specify the text, variables and presentation of information to be displayed on the tab. |
| SPP 30.0 |
| The SYSTEM shall provide the ability to retrieve document attributes and place their value within a header, footer or cover sheet for paper submissions. |
| SPP 31.0 |
| The SYSTEM shall provide the ability to set the margins within the output PDF file. |
| SPP 33.0 |
| The SYSTEM shall provide the ability to specify a pagination string to be used for a publication. |
| SPP 34.0 |
| The SYSTEM shall provide the ability to specify a pagination string to be used for pagination of a specified document range. |
| SPP 36.0 |
| The SYSTEM shall provide the ability to indicate when a PDF rendition does not exist for a document. |
| SPP 37.0 |
| The SYSTEM shall provide the ability for the user to specify what components should be included in the Table of Contents. |
| SPP 38.0 |
| The SYSTEM shall generate Tables of Contents in an editable format. |
| SPP 39.0 |
| The SYSTEM shall provide the ability to render XML files for inclusion in paper submissions. |
4.2.6 Submission Viewing, Distribution and Archival Category
| SV 1.0 |
| The SYSTEM shall provide the ability for users to view the structure and content of a completed submission. |
| SV 2.0 |
| The SYSTEM shall display sequence number and leaf operations (new, appended, replace, delete) in the working view of a submission assembly, and sequence number in the submitted and sequence view. |
| SV 3.0 |
| The SYSTEM shall show current, cumulative and sequence views. |
| SV 4.0 |
| The SYSTEM shall provide the ability to show metadata information for each submission. |
| SV 5.0 |
| The SYSTEM shall show sequence list with dates and submission types. |
| SV 6.0 |
| The SYSTEM shall show chronological and related sequence views. |
| SV 7.0 |
| The SYSTEM shall provide simultaneous review function allowing more than one user to review the document but not edit a document. |
| SV 8.0 |
| The SYSTEM shall provide a way to review the full eCTD submission/application. |
| SV 9.0 |
| The SYSTEM shall provide the ability to export a submission assembly for archiving. |
| SV 10.0 |
| The SYSTEM shall provide the ability to view the cumulative eCTD or changes between individual sequences (e.g. 0002 to 0003) via a standard internet browser. |
| SV 11.0 |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .