N62645-15-R-1007.pdf

SEE ADDENDUM

(No Collect Calls)

N62645-15-R-1007 22-Apr-2015

b. TELEPHONE NUMBER

301-619-1086

8. OFFER DUE DATE/LOCAL TIME

01:00 PM 26 May 2015

5. SOLICITATION NUMBER 6. SOLICITATION ISSUE DATE

AUTHORIZED FOR LOCAL REPRODUCTION

PREVIOUS EDITION IS NOT USABLE

STANDARD FORM 1449 (REV. 2/2012)

Prescribed by GSA – FAR (48 CFR) 53.212

(TYPE OR PRINT)

(SIGNATURE OF CONTRACTING OFFICER)

ADDENDA X ARE

26. TOTAL AWARD AMOUNT (For Gov t. Use Only )

23.

CODE 10. THIS ACQUISITION IS

SUCH ADDRESS IN OFFER

17b. CHECK IF REMITTANCE IS DIFFERENT AND PUT

BELOW IS CHECKED

TELEPHONE NO.

N626459. ISSUED BY

18b. SUBMIT INVOICES TO ADDRESS SHOWN IN BLOCK 18a. UNLESS BLOCK

7. FOR SOLICITATION

INFORMATION CALL:

a. NAME

BRIAN D. MILLER

2. CONTRACT NO. 3. AWARD/EFFECTIVE DATE 4. ORDER NUMBER

(TYPE OR PRINT)

30b. NAME AND TITLE OF SIGNER 30c. DATE SIGNED 31b. NAME OF CONTRACTING OFFICER

30a. SIGNATURE OF OFFEROR/CONTRACTOR 31a.UNITED STATES OF AMERICA

27a. SOLICITATION INCORPORATES BY REFERENCE FAR 52.212-1. 52.212-4. FAR 52.212-3. 52.212-5 ARE ATTACHED.X

25. ACCOUNTING AND APPROPRIATION DATA

1. REQUISITION NUMBER

20.

ADDITIONAL SHEETS SUBJECT TO THE TERMS AND CONDITIONS SPECIFIED.

OFFEROR TO COMPLETE BLOCKS 12, 17, 23, 24, AND 30

SOLICITATION/CONTRACT/ORDER FOR COMMERCIAL ITEMS

SEE SCHEDULE

ARE NOT ATTACHED

27b. CONTRACT/PURCHASE ORDER INCORPORATES BY REFERENCE FAR 52.212-4. FAR 52.212-5 IS ATTACHED. ADDENDA ARE ARE NOT ATTACHED

(BLOCK 5), INCLUDING ANY ADDITIONS OR CHANGES WHICH ARE

SET FORTH HEREIN, IS ACCEPTED AS TO ITEMS:

. YOUR OFFER ON SOLICITATION

28. CONTRACTOR IS REQUIRED TO SIGN THIS DOCUMENT AND RETURN

% FOR:SET ASIDE:UNRESTRICTED ORX

SMALL BUSINESS

17a.CONTRACTOR/ CODE FACILITY

OFFEROR CODE

NAVAL MEDICAL LOGISTICS COMMAND

693 NEIMAN STREET

FORT DETRICK MD 21702-9239

18a. PAYMENT WILL BE MADE BY CODE

RATED ORDER UNDER

DPAS (15 CFR 700)

13a. THIS CONTRACT IS A

13b. RATING

CODE15. DELIVER TO CODE N00000 16. ADMINISTERED BY

12. DISCOUNT TERMS11. DELIVERY FOR FOB DESTINA-

TION UNLESS BLOCK IS

MARKED

SEE SCHEDULE

14. METHOD OF SOLICITATION

RFQ IFB RFPX

SEE ATTACHED SITE LISTING

SEE ATTACHED SITE LOCATIONS

SEE SITE LOCATIONS AA VARIOUS

TEL: FAX:

FAX:

TEL: SERVICE-DISABLED

VETERAN-OWNED

SMALL BUSINESS

8(A)

HUBZONE SMALL

BUSINESS

SIZE STANDARD:

$38,500,000

NAICS:

511210

X

OFFER DATED

29. AWARD OF CONTRACT: REF.

DELIVER ALL ITEMS SET FORTH OR OTHERWISE IDENTIFIED ABOVE AND ON ANY

COPIES TO ISSUING OFFICE. CONTRACTOR AGREES TO FURNISH AND

EMAIL:

TEL:

31c. DATE SIGNED

SEE SCHEDULE

SCHEDULE OF SUPPLIES/ SERVICESITEM NO. QUANTITY UNIT UNIT PRICE AMOUNT

24.22.21.19.

WOMEN-OWNED SMALL BUSINESS (WOSB)

ELIGIBLE UNDER THE WOMEN-OWNED

SMALL BUSINESS PROGRAM

EDWOSB

32g. E-MAIL OF AUTHORIZED GOVERNMENT REPRESENTATIVE

SOLICITATION/CONTRACT/ORDER FOR COMMERCIAL ITEMS

(CONTINUED)

PAGE 2 OF59

ACCEPTED, AND CONFORMS TO THE CONTRACT, EXCEPT AS NOTED: ______________________________________________________

32a. QUANTITY IN COLUMN 21 HAS BEEN

RECEIVED INSPECTED

32b. SIGNATURE OF AUTHORIZED GOVERNMENT

REPRESENTATIVE

32c. DATE 32d. PRINTED NAME AND TITLE OF AUTHORIZED GOVERNMENT

REPRESENTATIVE

32e. MAILING ADDRESS OF AUTHORIZED GOVERNMENT REPRESENTATIVE 32f . TELEPHONE NUMBER OF AUTHORIZED GOVERNMENT REPRESENTATIVE

37. CHECK NUMBER

FINALPARTIALCOMPLETE

36. PAYMENT35. AMOUNT VERIFIED

CORRECT FOR

34. VOUCHER NUMBER

FINAL

33. SHIP NUMBER

PARTIAL

38. S/R ACCOUNT NUMBER 39. S/R VOUCHER NUMBER 40. PAID BY

41a. I CERTIFY THIS ACCOUNT IS CORRECT AND PROPER FOR PAYMENT

41b. SIGNATURE AND TITLE OF CERTIFYING OFFICER 41c. DATE

42a. RECEIVED BY (Print)

42b. RECEIVED AT (Location)

42c. DATE REC'D (YY/MM/DD) 42d. TOTAL CONTAINERS

STANDARD FORM 1449 (REV. 2/2012) BACK

Prescribed by GSA – FAR (48 CFR) 53.212

AUTHORIZED FOR LOCAL REPRODUCTION

PREVIOUS EDITION IS NOT USABLE

SEE SCHEDULE

20.

SCHEDULE OF SUPPLIES/ SERVICES

21.

QUANTITY UNIT

22. 23.

UNIT PRICE

24.

AMOUNT

19.

ITEM NO.

N62645-15-R-1007

Section SF 1449 - CONTINUATION SHEET

ITEM NO SUPPLIES/SERVICES QUANTITY UNIT UNIT PRICE AMOUNT

0001 1 Lot

DOFEMS

FFP

Defense Optical Fabrication Enterprise Management System

Offerors are required to provide a detailed description of components along with pricing.

FOB: Destination

MILSTRIP: N6264514RCP3004

PURCHASE REQUEST NUMBER: N6264514RCP3004

NET AMT

ITEM NO SUPPLIES/SERVICES QUANTITY UNIT UNIT PRICE AMOUNT

0002 1 Lot

DATA WAREHOUSE

FFP

Offerors are required to provide a detailed description of components along with pricing.

FOB: Destination

MILSTRIP: N6264514RC6P001

PURCHASE REQUEST NUMBER: N6264514RC6P001

NET AMT

INSTRUCTIONS TO OFFERORS

DoD established the Naval Medical Logistics Command (NMLC) as the Executive Agent for overseeing and directing business process reengineering efforts across the Optical Fabrication Enterprise (OFE). Within the Navy, the Naval Ophthalmic Support and Training Activity (NOSTRA) is the command responsible for performing these objectives. To achieve the vision for consistent customer service improvement, a standardized, enterprise-wide, global-reaching, optical fabrication Laboratory Management System (LMS) interfacing with existing and planned logistic, and electronic optical order entry programs across the DoD optical fabrication labs must be in place.

The North American Industry Classification System (NAICS) code for this requirement is 511210. The Small

Business Administration (SBA) size standard for this NAICS code in millions of dollars is $38.5. All qualified offerors are invited to submit a proposal.

This section specifies the format and content that offerors shall use in response to this solicitation. Offerors shall submit a response that is legible and comprehensive enough to provide the basis for a sound evaluation by the

Government. Any response which does not provide, as a minimum, that which is required within this solicitation may be determined to be substantially incomplete and not warrant any further consideration.

Delivery

The Contracting Officer reserves the right to adjust the start date of the contract based on the actual award date.

Period for Acceptance of Offers

The period for acceptance of offers is one hundred twenty (120) days after the closing date of the solicitation.

Pre-Contract Costs

The Contractor will not be reimbursed for any costs incurred prior to the effective date of the contract.

Questions

Any questions must be addressed to brian.d.miller1.civ@mail.mil by email only no later than 2:00 pm local time on

29 April 2015.

No phone calls will be accepted.

Responses

All responses should be submitted to Brian Miller at brian.d.miller1.civ@mail.mil.

Subject line should read: Solicitation # N62645-15-R-1007

Emails shall be no larger than 10MB

Responses may be submitted as MS Word, MS Excel or Adobe PDF attachments only.

All responses shall provide the following company details on their cover page:

Complete company name and address

Company Point of Contact (POC)

Email

Phone Number

CAGE Code

DUNS number

Place of Manufacture

Technical Approach

The contractor shall submit sufficient documentation to allow for an evaluation of the Technical Approach of the proposed system to meet the Statement of Requirements.

Conformance to Information Assurance (IA)

The C&A Questionnaire for the Department of Navy can be found at http://www.med.navy.mil/sites/nmlc/Pages/default.aspx. On the home page, click the Requests for

Proposals (RFPs) link on the left hand side of the site. Scroll to the bottom of the page where the questionnaire information is located and click the link to compete the questionnaire. In addition the

Department of Navy has an IA section that follows the Statement of Requirements.

The Department of Army questionnaire is included within this solicitation. It’s titled “Army IA” and it follows the Statement of Requirements.

mailto:brian.d.miller1.civ@mail.mil mailto:brian.d.miller1.civ@mail.mil http://www.med.navy.mil/sites/nmlc/Pages/default.aspx

The total number of the pages, excluding a cover letter, for Technical Approach is fifty (50) pages. If the Technical

Approach contains more than the mandated page count then only the first fifty (50) pages will be evaluated. The IA requirements are not included in the mandatory page count.

Past Performance

Offerors may provide recent and relevant contracts for the same or similar items and other references for up to five (5) data points within the last three (3) years. Past performance older than three (3) years will be considered not relevant. The Government reserves the right to consider other past performance information at its disposal, in addition to any information obtained from the references provided above.

The data shall for each reference shall include:

o Organization/Location o Valid POC with phone number and email o Contract Number o Contract Date o Total Contract Value o Description of the requirement

Description of the past performance provided under the contract to include types of work performed, and if subcontracts were utilized (Answer "Were Subcontractors used?” (Yes or No).

The total number of the pages submitted for past performance shall not exceed seven (7) pages, excluding a cover and consent letters. If past performance contains more than seven (7) pages, only the first seven (7) pages will be evaluated.

Price

Adequate price competition is expected for this acquisition. Offerors shall submit a pricing spreadsheet for all components related to this requirement.

The proposed price will be evaluated by the Government and must be determined to be fair and reasonable for award.

Offerors are registered in SAM at time of award, and have provided acknowledgement of the solicitation and all amendments. The solicitation shall be acknwledged through instructions in Block 28 and 30 of the

SF 1449. Each amendment shall be acknowledged through instructions in Block 11 of the SF 30. Signed copies of the cover page are acceptable. It is not necessary to submit the entire solicitation or amendment.

Completed DFARS 252.209-7992 provision.

Offerors shall be registered in the System for Award Management (SAM) database at time of award.

Registration is free and can be completed on-line at https://www.sam.gov/portal/public/SAM/.

Small Business Subcontracting Plan:

o If applicable (for other than small business concern offerors under the assigned NAICS code herein), the offeror shall submit a subcontracting plan in accordance with FAR Clause 52.219-9 and DFARS

Clause 252.219-7003 (for reference see FAR 19.704 and DFARS 219.704). The subcontracting plan requirement is not applicable to small business concerns qualified as such under the NAICS code assigned to this solicitation. Master subcontracting plans can be included as an appendix to the subcontracting plan.

o The Contracting officer will review the subcontracting plan for acceptability. If an offeror fails to negotiate a subcontracting plan acceptable to the Contracting Officer within the time limit prescribed by the Contracting Officer, the offeror will be ineligible for award.

o If the offeror believes there are no subcontracting possibilities, the offeror shall submit documentation sufficient to support its position.

Discussions

The Government intends to evaluate proposals and award a single contract without discussions with offerors. The

Government reserves the right to conduct discussions if the Contracting Officer later determines them to be necessary.

https://www.sam.gov/portal/public/SAM/

COR

Contracting Officer’s Representative (COR)

For the purpose of this clause, the COR is the duly authorized representative of the Contracting Officer.

The COR for this contract will be appointed at time of award.

The COR will perform inspection and acceptance of services to be provided. Inspection and acceptance will be performed at the locations listed in the contract.

STATEMENT OF REQUIREMENTS

1. BACKGROUND

DoD established the Navy as the Executive Agent for overseeing and directing business process reengineering efforts across the Optical Fabrication Enterprise (OFE). Within the Navy, the Naval Ophthalmic Support and

Training Activity (NOSTRA) is the command responsible for performing these objectives. This requirement is to achieve the vision for consistent customer service improvement.

The OFE is comprised of 27 labs. The combined fabrication of all labs has been as high as 1.7 million orders annually but that number could increase.

2. REQUIREMENT

Defense Optical Fabrication Enterprise Management System (DOFEMS) is a standardized, enterprise-wide, global-reaching, optical fabrication Laboratory Management System (LMS) interfacing with existing and planned logistic, and electronic optical order entry programs and including a data warehouse to provide visibility of fabrication information across the DoD optical fabrication labs. The new requirement will be replacing the existing LMS systems that is currently in place at NOSTRA. An optical fabrication LMS system’s function is to control and communicate with lens production and inspection machines used in the manufacture of prescription eyewear. It also serves as an order processing system which has the capability of retrieving orders from remote ordering systems and processing them for fabrication. It includes Financial Management and Inventory Management capabilities.

This requirement shall include on-site installation for 20 of the 27 optical labs (see labs listed in section 3), customizations, configuration and testing, serial connectivity to Optical Manufacturers Association (OMA) devices, serial laser barcode scanner readers, all hardware necessary to operate the systems, hands on training, and system manuals. Also, the warranty shall be for one year and include software maintenance program updates, technical support available 0500 – 1700 Monday through Friday for all time zones where labs are located, and two (2) on-site service support visits per year to the two major surfacing labs in Yorktown and San Antonio). During deployment of the system, the Government will decide if some features such as Inventory Management and/or Financial

Management may be enabled or disabled based for site specific capabilities. In addition, responses shall include either on-site and/or phone support when new or replaced equipment is required to be connected to the system during the warranty period.

2.1 LMS

The LMS shall interface with the Spectacle Request Transmission System (SRTS) with metrics reporting to the

DOFEMS Management Warehouse Interface for optical orders and production statistics. The software system shall be designed to support the large laboratories; however the small and medium facilities may choose to disable certain functions of the system. The software shall be configured to enable or disable functions such as the Financial

Management and/or Inventory Management functions.

At a minimum, the LMS application shall provide:

One-direction Interface with the DOFEMS Management Oversight Warehouse

Bi-directional interface with the Spectacle Request Transmission System (SRTS)

Authenticated access control, Operator role-based access control (Production, Quality, Shipping, Material/Supply Management, Finance, and Command Reporting)

Data exchange with optical fabrication equipment using OMA standards

Customer Service capability for manual order input and local data table maintenance

Detailed job workflow tracking capabilities

Capture daily shipping activities: print shipping and/or individual address labels, capturing ship date, and shipping vendor

The system shall capture inventory usage using Optical Product Code (OPC) and description

Allow manual capture of quality identified rework requirements and production line breakages.

2.1.1 Inventory Management

At a minimum, the LMS shall provide the following Inventory Management capabilities:

Real time inventory management

Ability to perform lens/pick validation

Attach lens/frame stock OPC barcode standard for lenses by lens manufacturer to bin for stock pulling

Compute inventory levels based on usage history

Identify “slow moving” inventory based on OFE site existing inventory and provided parameters

Allow for manual update of frame and lens information such as deletions/additions/changes.

2.1.2 Financial Management

At a minimum, the LMS shall provide the following Financial Management capabilities:

Process accounts payable, accounts receivable and bill customers.

Manually calculate cost tables and average for manual inputs and updates.

Accounts payable are applied to only a unique sub-set of customers calculated by Service Component and location. The accounts are billed on a monthly basis by location.

Accounts receivable are funded through a Government funding document.

Produce an invoice for designated accounts – see Attachment I titled “Invoice.”

2.1.3 Reports

At a minimum, the LMS shall provide the following reporting capabilities for each lab:

Requires a near real time service oriented dashboard that is highly configurable by the user.

User friendly report builder allowing ad-hoc queries on all fields in the database

Canned report suite

Multiple jobs history report reflecting work in progress detail

Microsoft exportable capability

2.2 Data Warehouse

The Data Warehouse shall provide enterprise level oversight of all global optical fabrication laboratories within the

OFE by using a Wide Area Network (WAN) allowing for inter-site connectivity via web interfaces or client software processing unclassified sensitive information. It shall be integrated to interface with all of the LMS applications at all labs listed in Section 3, OFE Laboratories. The Data Warehouse will be located at Naval

Ophthalmic Support and Training Activity (NOSTRA) in Yorktown, VA.

Shall have job tracking among labs by integrating the components below into a central “dashboard” display that is easy to read and intuitive to operate. Other management features shall include:

Batch process data from the OFE lab management database systems every two hours

Two-hour batch processing of lab production data in order to assess performance metrics and establish enterprise effectiveness

Track and report order fill requirements and productivity statuses at each lab, primarily work in process and orders sold (shipped)

Integrate OFE local inventory management across all sites, identifying frame and lens stock and biggest selling frames

Provide Summarized and Customized Reports by site o Average time from order received to shipped o Work in Process (as specified by day, week, month, year) o First time pass rate o Reject totals o Daily received totals o Daily ship total o Reimbursable items sold

Accurate laboratory statistics o Web based query by hour, day, month and year on varying data o View current and 3 year historical production output by site, Component Branch, unit identification code (UIC) o Current Work-in-Progress (WIP) in real time or constraints based interface and local network architecture framework.

3. OFE Laboratories

3.1 Installation of DOFEMS shall be done in the following labs:

Optical Fabrication Enterprise (OFE)

Navy Fabrication Labs Size Army Fabrication Labs Size

Camp Lejeune, North Carolina Small Tripler, Hawaii Small

Camp Pendleton, California Small Fort Knox, Kentucky Small

Great Lakes, Illinois (FHCC G/L) Small Fort Leonard Wood, Missouri Med

Mayport, Florida Small Fort Sill, Oklahoma Med

Newport, Rhode Island Small Fort Benning, Georgia Med

Parris Island, South Carolina Small Fort Jackson, South Carolina Large

Pensacola, Florida Small Fort Sam Houston, Texas (BAMC) Large

Quantico, Virginia Small

Sewell’s Point (Norfolk) Virginia Small

Walter Reed, Maryland Small

Bremerton, Washington Med

San Diego, California Med

Yorktown, Virginia (NOSTRA) Large

3.2 Hardware Requirements

3.2.1 Barcode Scanners

Small labs shall be provided 10 barcode scanners

Medium labs shall be provided 20 barcode scanners

Large labs shall be provided 50 barcode scanners

3.2.2 Server Requirements

Vendor shall provide server hardware and operating system software to support LMS software.

3.2.3 Other Hardware

Vendor shall provide Digi TS Portserver serial to IP switches that support RealPort protocol.

4. Information Technology (IT) Requirements

4.1 Interfaces

4.1.1 All OMA compliant equipment and tooling that allow an optical order to be received from an external customer, validated, tracked, calculated, manufactured, verified, and shipped to the external customer

4.1.2 Spectacle Request Transfer System (SRTS) – Each site LMS shall have a real time interface with the SRTS system, a web based ordering system. Ordering is performed using the DD771- see Attachment II. Data elements are listed in the form and are consistent across the enterprise.

4.1.3 Data Warehouse

Each site will have an asynchronous interface with the data management warehouse.

4.2 IT Policies and Requirements

4.2.1 Department of Army Information requirements See section titled Army IA for additional language.

4.2.2 Department of Navy Information requirements See section titled Navy IA for additional language.

5. Section 508 Requirement

The contractor shall comply with Section 508 of the Rehabilitation Act of 1973 (29 U.S.C. 794d). Specifically, the procurement, development, maintenance, or integration of electronic and information technology (EIT) under this contract shall comply with the applicable accessibility standards issued by the Architectural and Transportation

Barriers Compliance Board at CFR part 1194.

ARMY IA

US Army Cybersecurity Solicitation Questionnaire

Cybersecurity Assessment and Authorization Process Overview: The Cybersecurity Process Overview, from a high-level vantage point, involves the following: identification of vulnerabilities within the vendor’s product;

remediation of vulnerabilities through the vendor’s software change processes within scope of the FDA certification to maintain the product’s safety and efficacy; mitigation of un-remediated vulnerabilities; independent assessment of the security baseline of the product; and a risk-acceptance decision from the Military Authority responsible for maintaining the security of the network. This Military Authority is called the Authorization Official (AO).

The critical date to the process is the conduct of the independent assessment of the security baseline of the product.

This assessment is known as a “Security Controls Assessment”, and is conducted by be a government team that is not part of the program management office responsible for the contract action. The Security Controls Assessment

Report is generated typically within 30 days of the assessment and provides the security baseline that is considered by the AO. In turn, the vendor’s remediation actions and mitigations will be provided in response to the report to address all identified vulnerabilities. A typical Cybersecurity Accreditation Process schedule of events involving the vendor is shown in table 1.

Table 1, Example of Typical Cybersecurity Accreditation Process Schedule

Milestone Responsibility Due Date

Post Award Conference Government ≤ 10 working days from Contract Award

Complete System Information Profile

(SIP) and DIACAP Implementation Plan

(DIP)

Vendor ≤ 15 working days from receipt of draft SIP &

DIP, and prior to product delivery.

Conduct initial security testing and deliver test results to the Government

Vendor ≤ 20 working days from Post Award

Conference

Deliver Vulnerability Report (a.k.a.

unmitigated POA&M) to vendor

Government ≤ 15 working days from receipt of initial security test results

Deliver Remediation Plan (a.k.a. Vendor ≤ 30 working days from receipt of the

POA&M with Milestones, Remediation

Actions, or Mitigation Actions)

Vulnerability Report from ICS PMO IA

Conduct remediation and mitigation activities identified in the Remediation

Plan)

Vendor 40 working after delivery of Remediation Plan

Participate in Security Controls

Assessment

Vendor As scheduled at the Post Award Conference

Provide notice to proceed with delivery only after positive Accreditation

Decision is received

Government 45 Working days after testing is completed.

Upon receipt of the Accreditation Package, the AO will make a risk acceptance decision. The risk acceptance decision will result in an Authority To Operate (ATO), Interim Authority To Operate (IATO), or a Denial of

Authority To Operate (DATO). An IATO will require ongoing work within a specified time frame for the vendor to conduct additional remediation of vulnerabilities. A DATO is a potential breach of contract due to the Vendor’s inability to meet DoD Cybersecurity Requirements.

There is an expectation that new vulnerabilities are addressed in all networked devices while support for the product is available. The Cybersecurity Accreditation Process provides an ATO that is valid for a specified timeframe.

There will be periodic reviews of the security baseline with the need to update the list of known vulnerabilities, associated remediation actions to close existing or newly identified vulnerabilities, and new mitigations for those un-remediated vulnerabilities. These actions should be considered in the vendor’s response for maintenance and sustainment.

Food and Drug Administration Premarket Submission Content: The Food and Drug Administration (FDA)

Guidance for the Content of Premarket Submissions for Management of Cybersecurity in Medical Devices calls for the vendor to provide additional cybersecurity-related documentation in paragraph 6 of the Guideline. The additional cybersecurity-related documentation has relevance in medical device acquisistion. The FDA recommendations are predicated on an effective implementation and management of a quality system in accordance with the Quality System Regulation, including Design Controls.

As part of the solicitation response, provide the date of the premarket submission for the medical device. While not regulatory in nature, a vendor’s ability to produce this cybersecurity documentation for products that underwent premarket submission after 02 October 2014 is an indication of the vendor’s commitment to providing secure medical devices. If the premarket submission occurred before 02 October 2014, there is no expectation that this documentation be present. However, statethat the product underwent premarket submission before 02 October

2014.

Provide a summary describing the plan for providing validated software updates and patches as needed throughout the lifecycle of the medical device to continue to assure its safety and effectiveness in accordance with FDA

Guidance for the Content of Premarket Submissions for Management of Cybersecurity in Medical Devices.

Provide a summary describing the controls that are in place to assure that the medical device software will maintain its integrity (e.g. remain free of malware) from the point of origin to the point at which that devices leaves the control of the manufacturer of the security baseline of a product and the vendor’s capability to meet DoD and U.S.

Amy Cybersecurity requirements.

Provide device instructions for use and product specifications related to recommended cybersecurity controls appropriate for the intended use environment (e.g. anti-virus software, use of firewall).

Manufacturer’s Disclosure Statement for Medical Device Security (MDS2): The MDS2 is a standard produced by the National Electrical Manufacturers Association and the Healthcare Information and Management Systems

Society that is “intended to assist professionals for security risk assessment processes in their management of medical device security issues.” (HN 1-2013, page 1) The MDS2 provides an industry accepted standard to disclose information that helps to identify the cybersecurity baseline of a medical device. While this standard is comprehensive, it does not address all the information needs required by DoD Medical Acquisistion Personnel to assess the cybersecurity baseline in context of a DoD network. In addition to providing the information called for in

MDS2 instructions, provide additional information requested below in the Supplemental Instructions to assist in assessing the security baseline of the product.

The MDS2 can be found on National Electrical Manufacturers Association website at http://www.nema.org/Standards/Pages/Manufacturer-Disclosure-Statement-for-Medical-Device-Security.aspx. The standard includes the instructions for completion of the MDS2. The MDS2 form HN 1-2013 is found at http://www.nema.org/Standards/ComplimentaryDocuments/MDS2 form HN 1-2013.xlsx.

The following items are Supplemental Instructions to the instructions found in the MDS2 standard toclarify the amount of information requested in the MDS2. It will be referred by the major area of the MDS2 and item number.

Management of Privte Data, B: Provide specific information on the types of private data maintained to allow for an assessment of whether the Medical Device will fall under an existing Privacy Impact Assessment (PIA) or require another PIA. The conduct of a new PIA increases that amount of government resources required for successful implementation and also has potential to increase the PMs Implementation schedule.

Security Capabilities, Automatic Logoff, 1: Provide a specific statement with regards to the clinical capability impacts if Automatic Logoff is not enable. With sufficient clinical workflow justification about the potential of patient harm due to lack of immediate accessibility, the government Program

Manager and Cybersecurity Program Manager are able present recommendations to the AO to accept risk.

Security Capabilities, Audit Controls, 1: Provide notes as to the retention periods of the audit logs, and if the retention period is configurable. Annotate in the note the system response if the audit logs are completely filled. The vendor should also annotate how access to the audit logs is controlled.

Additionally, Annotate if the audit logs are able to be stored on a central audit log server.

Security Capabilities, Malware Detection/Protection: Annotate in the notes which Anti-malware products that the vendor approves to be used with the medical device.

Security Capabilities, Person Authentication, 1: Annotate in the notes whether the medical device utilizes LDAP or Active Directory. The vendor should also annotate whether smart cards (Common

Access Card) and PKI can utilized for login. If a group account is used for the end user access to the system, Provide justification in terms of clinical capability and accessibility. For password authentication, state the password complexity rules.

Security Capabilities, Health Data Storage Confidentiality, 17: State the encryption algorithms that can be used for Data in Transit encryption.

Security Capabilities, Transmission Confidentiality, 18: State the encryption algorithms that can be used for Data At Rest encryption.

Security Capabilities, Transmission Confidentiality, 18-2: Provide detail on: the types of removable media that is utilized by the product, the necessity of utilization of removable media in the clinical workflow, and also address the ability of the vendor to disable components that read and write to removable media.

Department of Defense (DoD) Specific Cybersecurity Information Requirements: Provide in the response to the solicitation, the information requested below to provide specific insight to technical design considerations that have significant impact on the ease of implementation of a Medical Device into a DoD Network

System Description: Provide a detailed System Description of the medical device that has a minimum set of Medical Device configuration information. The purpose of the detailed System Description is to http://www.nema.org/Standards/Pages/Manufacturer-Disclosure-Statement-for-Medical-Device-Security.aspx http://www.nema.org/Standards/ComplimentaryDocuments/MDS2%20form%20HN%201-2013.xlsx identify all components, and interfaces that allows for the assessment of the Medical Device cybersecurity baseline. This assessment includes reviewing the components of the Medical Device to identify components not approved for use on the DoD Network, such as specific versions of Operating

Systems (i.e. Windows XP). Unapproved components may prevent the connection of the Medical

Device to the network.

Provide details on the software utilized in the medical device to include software name and version.

This is all encompassing and should include Operating Systems, Software Applications, Database

Applications and any other software utilized.

Table 2, Software Components

Application Name/Version HW Installed On Purpose

Example:

Oracle v.8.1

Database Server Data storage and retrieval

Identified third party software and hardware components. For third party software, elaborate on the vendor’s willingness to make configuration changes either through their own or the third party’s software change request processes at no additional cost. Additionally, state whether they have administrative access to the third party component to facilitate basic administrative actions, such as conduct of vulnerability scans.

Table 3, Third Party HW/SW Components

Third Party HW/SW

Component

Make/Model

Version

Purpose / Ability to Change

Configuration

Connected to

Example:

ACME Video Processing

Unit

Brand X/Model A Capture still, digital images

Vendor has System

Administrator Privileges

PACS workstation

Example:

Bronchoscopic Camera

Brand X/Model Y Capture digital video images

Vendor cannot make changes and does not have System

Administrator Privileges

PACS workstation

Provide the list of ports, protocols, and services essential to the operation of the system.

Table 4, Ports, Protocols, and Services

Protocol/Services

Used

TCP/

UDP

Low

Port

High

Port Purpose

Inbound/O utbound Notes/Description

EXAMPLE TCP 80 80 HTTP Inbound

Used to host internal webpage for image viewing

EXAMPLE 2 TCP 21 22 FTP In/Out

Used to send archive information to PACS

Identify remote maintenance mechanisms, to include the software components, in the System

Description. An example of a remote maintenance mechanism is any remote desktop software, such as

PC Anywhere.

Provide details on the ability of system to run in a virtualization environment that includes: the virtualized environment(s) that the vendor has certified their product to use; and the configuration requirements for the virtual machine.

Provide details on the System Usernames and Roles. The System Usernames should include all accounts with any level of administrative privileges for the operating system, databases, and other system components. System usernames includes system accounts that are utilized by applications to conduct any function within the product.

Table 5, System Usernames and Roles

User Names and Roles

Username Role Description

XAdministrator Administrator Built in Admin account - Disabled

ScanTech Power User Auto login service account that launches the application

TechSupport Administrator <VENDOR> service account for onsite support

LIST ANY ACCOUNTS ON THE SYSTEM AND THE REASON FOR THEM BEING THERE

System Diagrams are critical evaluation of the baseline cybersecurity status. Provide system diagrams, in Visio file format, shown in Figure 1 (See Attachment #III). Provide information for any internal and external interfaces required for the system to operate as intended. A brief description of the connection and it’s operational purpose should be included below the diagram. Details like accreditation boundary and external interfaces may be combined in one diagram as long as it clearly communicates the required information.

Supply system configuration information and published system guides. These system guides may include the

System User Guide (Operational Manual), System Administrator’s Guide, and Secure Features Usability Guide. If these system guides are not available, state so in the response.

Internet Protocol version 6: The current network protocol, Internet Protocol, version 4 (IPv4), has reached the end of its life, and can no longer expand to meet demand. In August 2005, the Office of Management and Budget

(OMB) issued Memorandum M-05-22, “Transition Planning for Internet Protocol Version 6 (IPv6)” requiring the deployment of IPv6 on Federal Government network backbones by June 2008. The Defense Acquisition

Regulations Council amended the FAR to require that IPv6-compliant products be included in all new IT acquisitions using Internet Protocol effective December 10, 2009.

As part of the response to a solicitation request, provide documentation, if available, that validates that the medical device in question is IPv6 capable or will be IPv6 capable no later than the official system acceptance. IPv6

‘capable’ is defined as having the capability of receiving, processing and forwarding IPv6 packets and/or interfacing with other IPv6 capable systems/devices and in a manner similar to IPv4.

The requirements that we have to consider are listed in the Federal Acquisition Regulation (FAR) 7.105(b)(4). The system proposed by the vendor shall be Internet Protocol version 6 (IPv6) capable or the vendor must request a waiver by providing a detailed project or planning documentation to show that the proposed system shall be IPv6 capable no later than official system acceptance testing. The requirements are as follows:

Conformant with the IPv6 standards profile contained in the DoD IT Standards Registry

(DISR);

Conformant per DoD IPv6 Generic Test Plan, v.4 May 2009;

Conformant per DoD IPv6 Product Profile, v.4 July 2009.

Maintaining interoperability in heterogeneous environments with IPv4;

Commitment to upgrade as the IPv6 standard evolves;

Availability of vendor IPv6 technical support.

Host Based Security System (HBSS): The HBSS security suite protects Microsoft (MS) Windows-based

MEDCOM endpoint devices, such as, but not limited, to workstations, laptops, and servers. HBSS is a McAfee commercial off-the-shelf software (COTS) solution capable of detecting cyber threats in real time and responding appropriately to protect MEDCOM clients or hosts (i.e., servers, workstations, and laptops). HBSS consists of Host

Intrusion Protection System (HIPS), Antivirus (AV), and centrally managed tools that scan for anomalies, monitor compliance, and manage group policies.

For Windows Based systems, provide documentation in the solicitation response on the capability to utilize HBSS with the medical device.

If testing of HBSS usage with the product has not occurred, state that testing has not occurred and also the willingness of the vendor to conduct HBSS testing at their own expense.

If HBSS has been tested for use with the product, provide details on compatibilities or incompatibilities with all or specific components of HBSS. This should include whether

HBSS will be installed and/or managed by the vendor or the site and what components (OS, Applications, DB, etc.) will need to be managed as exceptions. The compatibilities or incompatibilities should be identified in the vendor’s response.

Open Source Software (OSS): The 16 October 2009 memorandum from the DoD CIO, "Clarifying Guidance

Regarding Open Source Software (OSS)" defines OSS as "software for which the human-readable source code is available for use, study, re-use, modification, enhancement, and re-distribution by the users of that software". DoD cybersecurity limits the use of OSS, public domain software or other software products with limited or no warranty on the grounds that these items are difficult or impossible to review, repair, or extend, given that the Government does not have access to the original source code and there is no owner who could make such repairs on behalf of the government. This control should not be interpreted as forbidding the use of OSS, as the source code is available for review, repair and extension by the government and its contractors. As part of the response to a solicitation request, if the vendor product has OSS, provide basic documentation that indicates one or more of the following about the

OSS:

On a DoD or DA approved products list

A utility that has publicly available source code that is acceptable by DoD

A commercial product where the medical device vendor provides a warranty

A commercial product from a third party commercial vendor that provides a warranty

Wireless: Advances in wireless signaling technology have led to a growth in the methods of wireless transmission, as well as allowed for increased transmission distances. Without the use of encryption and authentication protocols, transmitted data can be read and deciphered by unintended recipients in a matter of seconds. In addition, wireless signals are susceptible to attacks through radio interception devices or jammed intentionally by other wireless and/or electromagnetic devices. Depending on the transmission method, DoD has identified specific encryption requirements that may include hardware and/or software. As part of the response to a solicitation request, if the vendor product is wireless capable, Provide documentation that validates that the medical device in question meets

DoD data transmission requirements. The solicitation documentation should also identify that an approved encryption in transit is a requirement that will have to be met for the Medical Device before official system acceptance.

Continuity: Continuity of medical systems is critical to the on-going execution of the medical mission. Continuity is addressed through maintenance processes, back-up processes, and restoration processes.

Describe the availability of system support and the ability to provide maintenance parts to technicians at a local site.

Provide detailed information on how the product can be restored back to operation in the event of a system failure and the expected timelines.

Provide a description of the back-up procedures. If the back-up procedures are annotated in a manual that the vendor is providing in response to the solicitation, the vendor may reference the manual.

Provide a description of the ability to send back-ups to a remote system, type of encryption used to encrypt a back-up and type of encryption utilized if the back-up is sent to a remote system.

Describe how The system maintains a secure state during shutdown and restart processes; meaning:

No object reuse occurs that could accidentally compromise the confidentiality of the system data

Access to the system cannot be gained by unauthorized personnel

Unauthorized access to system resources cannot be gained by authorized system users

Shutdown and restart of the system will not cause harm to the patient, if it occurs during a procedure.

Data files are not corrupted in the event of an unscheduled shut down.

DoD Warning Banner: Provide a description of how the DoD Warning Banner will be incorporated into the product and a description of how the warning banner can be edited. The warning banner should be able to accomodate up to

1300 characters in the text. If the DoD Warning Banner cannot be implemented in the product, state “The DoD

Warning Banner cannot be implemented ,“ along with the reason.

DoD Warning Banner Content

You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.

By using this IS (which includes any device attached to this IS), you consent to the following conditions:

-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.

-At any time, the USG may inspect and seize data stored on this IS.

-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.

-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.

Figure 1, DoD Warning Banner Content

Theory of Operation: Provide a brief description of the clinical workflow that is involved with utilization of this product. The description should describe not only the human interactions, but how information is gathered and disseminated. For example, if patient demographics are collected or used to identify a patient within the product, how the demographics are loaded into the system should be described.

Personnel. Provide specific points of contact (POCs) in support of the accreditation efforts of the system as shown by the table below. Multiple roles may be satisfied by a single individual. The experience and certifications of each individual, with respect to cybersecurity, should be annotated in the table.

Table 6, Vendor Points of Contact

Vendor Personnel with IA Knowledge or IA Role

Individual (name and title) Cybersecurity Certifications and Experience

Product Manager:

IT Technical Lead:

IA Testing Lead:

Other/Additional: (Optional)

REFERENCES/APPLICABLE DOCUMENTS

DoDI 8500.01 “Cybersecurity”

DoDI 8510.01, “Risk Management Framework (RMF) for DoD Information Technology”

DoDI 8580.02-R “DoD Health Information Policy Regulation”

HIMSS/NEMA Standard HN 1-2013, Manufacturer’s Disclosure Statement for Medical Device

Security

Guidance for Industry and Food and Drug Administration Staff: Content of Premarket Submissions for

Management of Cybersecurity in Medical Devices, 02 October 2014

NAVY IA

All Department of the Navy (DON) information systems as defined in Department of Defense Directive (DoDD)

8500.1 shall be certified and accredited (C&A) for operation. C&A is attained via the Defense Information

Assurance Certification and Accreditation Process (DIACAP) and is applicable to all DON-owned or controlled information systems that receive, process, store, display or transmit Department of Defense (DoD) information, regardless of Mission Assurance Category (MAC) classification or sensitivity, except, per DoDD 8500.1 Paragraph

2.3; IT that is considered Platform Information Technology (PIT). Regardless of whether the system or device is considered PIT or whether it is determined that it requires a full accreditation, the following DIACAP artifacts shall be included with your proposal; System Identification Profile (SIP), DIACAP Implementation Plan (DIP), and Plan of Actions and Milestones (POA&M). Completion of the C&A Questionnaire in its entirety will satisfy the requirement for the SIP, DIP and POA&M.

The contractor shall establish appropriate administrative, technical, and physical safeguards to protect all government data, to ensure the confidentiality, integrity, and availability of government data under their control. At a minimum, this shall include provisions for personnel, electronic, and physical security.

Navy PIT Designation Certain medical technologies may be designated as PIT by the Navy Operational Designated Accrediting Authority

(ODAA); however the PIT designation itself does not constitute an Approval to Operate (ATO). The PIT system will require a PIT Risk Analysis (PRA). The DIACAP SIP, DIP, POA&M and Risk Analysis documents are required in order to complete a PRA. Contractors will be required to scan the PIT system for vulnerabilities prior to delivery.

According to DoDD 85001, Paragraph E2.1.16.4; PIT refers to computer resources, both hardware and software, that are physically part of, dedicated to, or essential in real time to the mission performance of special-purpose systems. Medical technologies, and specifically medical imaging and monitoring systems are considered special-purpose mission technologies according to this definition.

The PIT designation issued by the ODAA may be used by the Program Manager (PM) to complete a PRA in order to prove compliance with C&A requirements, but is cautioned that the appropriate IA controls must still be built into the IT to comply with acquisition requirements. The contractor shall work with Navy

Program Managers to ensure their systems meet these requirements.

The Contractor will be required to propose an acceptable approach to selecting IA controls starting from the baseline set on DoD Instruction 8500.2 B, commensurate with the system’s Mission Assurance

Category (MAC) and Confidentiality Level. For medical devices and systems the MAC level assigned is typically MAC III sensitive.

If the system or device is determined to be PIT, the Contractor shall support Navy Medicine IA representatives in creation of the PIT designation request packages to include all relevant configuration, software and IA data. The following documents will assist in creating the PIT designation request package;

o Digital Imaging and Communications in Medicine (DICOM) Conformance Statement (if applicable) o Food and Drug Administration (FDA) Certification (510k) o Integrating the Healthcare Enterprise (IHE) Integration Statement o International Organization for Standardization (ISO) Statement (if applicable) o Manufacturer Disclosure Statement for Medical Device Security (MDS2) o A full system diagram to include any PIT to PIT or other interconnections

DIACAP

For those systems that do not meet the requirements for designation as PIT, the contractor shall comply with

DIACAP requirements as specified by the DoD that meet appropriate DoD and Navy IA requirements. The contractor shall initiate the process by providing the required documentation necessary to receive an ATO. The contractor shall make their device or system delivered against this contract available for C&A testing and initiates the process well in advance of a contract delivery order. The requirements shall be met before the contractor's system is authorized to access DoD data or interconnect with any DoD network that receives, processes, stores, displays or transmits DoD data. An ATO, at a minimum, will be required before a device or system is installed. The contractor shall ensure that the proper contractor support staff is available to participate in all phases of the DIACAP process. They include but are not limited to;

• Completing and maintaining all documentation necessary to obtain an ATO.

• Attending…